summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-02-11Merge branch 'rs/parse-options-lithelp-help'Libravatar Junio C Hamano1-0/+5
Comment update. * rs/parse-options-lithelp-help: parse-options: document bracketing of argh
2022-02-11Merge branch 'bc/csprng-mktemps'Libravatar Junio C Hamano9-12/+169
Pick a better random number generator and use it when we prepare temporary filenames. * bc/csprng-mktemps: wrapper: use a CSPRNG to generate random file names wrapper: add a helper to generate numbers from a CSPRNG
2022-02-11Merge branch 'bc/clarify-eol-attr'Libravatar Junio C Hamano2-5/+12
Doc and test update around the eol attribute. * bc/clarify-eol-attr: docs: correct documentation about eol attribute t0027: add tests for eol without text in .gitattributes
2022-02-09The second batch for 2.36Libravatar Junio C Hamano1-1/+59
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-09Merge branch 'jc/mem-pool-alignment'Libravatar Junio C Hamano1-3/+23
Update the logic to compute alignment requirement for our mem-pool. * jc/mem-pool-alignment: mem-pool: don't assume uintmax_t is aligned enough for all types
2022-02-09Merge branch 'js/sparse-vs-split-index'Libravatar Junio C Hamano4-29/+33
Mark in various places in the code that the sparse index and the split index features are mutually incompatible. * js/sparse-vs-split-index: split-index: it really is incompatible with the sparse index t1091: disable split index sparse-index: sparse index is disallowed when split index is active
2022-02-09Merge branch 'jt/clone-not-quite-empty'Libravatar Junio C Hamano2-6/+21
Cloning from a repository that does not yet have any branches or tags but has other refs resulted in a "remote transport reported error", which has been corrected. * jt/clone-not-quite-empty: clone: support unusual remote ref configurations
2022-02-09Merge branch 'jt/sparse-checkout-leading-dir-fix'Libravatar Junio C Hamano2-0/+9
"git sparse-checkout init" failed to write into $GIT_DIR/info directory when the repository was created without one, which has been corrected to auto-create it. * jt/sparse-checkout-leading-dir-fix: sparse-checkout: create leading directory
2022-02-09Merge branch 'en/plug-leaks-in-merge'Libravatar Junio C Hamano2-6/+10
Leakfix. * en/plug-leaks-in-merge: merge: fix memory leaks in cmd_merge() merge-ort: fix memory leak in merge_ort_internal()
2022-02-09Merge branch 'ab/config-based-hooks-2'Libravatar Junio C Hamano27-158/+522
More "config-based hooks". * ab/config-based-hooks-2: run-command: remove old run_hook_{le,ve}() hook API receive-pack: convert push-to-checkout hook to hook.h read-cache: convert post-index-change to use hook.h commit: convert {pre-commit,prepare-commit-msg} hook to hook.h git-p4: use 'git hook' to run hooks send-email: use 'git hook run' for 'sendemail-validate' git hook run: add an --ignore-missing flag hooks: convert worktree 'post-checkout' hook to hook library hooks: convert non-worktree 'post-checkout' hook to hook library merge: convert post-merge to use hook.h am: convert applypatch-msg to use hook.h rebase: convert pre-rebase to use hook.h hook API: add a run_hooks_l() wrapper am: convert {pre,post}-applypatch to use hook.h gc: use hook library for pre-auto-gc hook hook API: add a run_hooks() wrapper hook: add 'run' subcommand
2022-02-09Merge branch 'fs/ssh-signing-crlf'Libravatar Junio C Hamano1-10/+24
The code path that verifies signatures made with ssh were made to work better on a system with CRLF line endings. * fs/ssh-signing-crlf: gpg-interface: trim CR from ssh-keygen
2022-02-09Merge branch 'jc/name-rev-stdin'Libravatar Junio C Hamano8-32/+72
"git name-rev --stdin" does not behave like usual "--stdin" at all. Start the process of renaming it to "--annotate-stdin". * jc/name-rev-stdin: name-rev.c: use strbuf_getline instead of limited size buffer name-rev: deprecate --stdin in favor of --annotate-stdin
2022-02-09Merge branch 'gc/fetch-negotiate-only-early-return'Libravatar Junio C Hamano4-3/+63
"git fetch --negotiate-only" is an internal command used by "git push" to figure out which part of our history is missing from the other side. It should never recurse into submodules even when fetch.recursesubmodules configuration variable is set, nor it should trigger "gc". The code has been tightened up to ensure it only does common ancestry discovery and nothing else. * gc/fetch-negotiate-only-early-return: fetch: help translators by reusing the same message template fetch --negotiate-only: do not update submodules fetch: skip tasks related to fetching objects fetch: use goto cleanup in cmd_fetch()
2022-02-09Merge branch 'pw/add-p-hunk-split-fix'Libravatar Junio C Hamano2-12/+56
"git add -p" rewritten in C regressed hunk splitting in some cases, which has been corrected. * pw/add-p-hunk-split-fix: builtin add -p: fix hunk splitting t3701: clean up hunk splitting tests
2022-02-09Merge branch 'tl/doc-cli-options-first'Libravatar Junio C Hamano1-5/+14
We explain that revs come first before the pathspec among command line arguments, but did not spell out that dashed options come before other args, which has been corrected. * tl/doc-cli-options-first: git-cli.txt: clarify "options first and then args"
2022-02-09Merge branch 'po/readme-mention-contributor-hints'Libravatar Junio C Hamano1-3/+11
Doc update. * po/readme-mention-contributor-hints: README.md: add CodingGuidelines and a link for Translators
2022-02-09Merge branch 'jt/conditional-config-on-remote-url'Libravatar Junio C Hamano4-41/+290
The conditional inclusion mechanism of configuration files using "[includeIf <condition>]" learns to base its decision on the URL of the remote repository the repository interacts with. * jt/conditional-config-on-remote-url: config: include file if remote URL matches a glob config: make git_config_include() static
2022-02-09Merge branch 'en/merge-ort-restart-optim-fix'Libravatar Junio C Hamano2-0/+71
The merge-ort misbehaved when merge.renameLimit configuration is set too low and failed to find all renames. * en/merge-ort-restart-optim-fix: merge-ort: avoid assuming all renames detected
2022-02-09Merge branch 'js/test-unset-trace2-parents'Libravatar Junio C Hamano1-0/+2
Avoid tests that are run under GIT_TRACE2 set from failing unnecessarily. * js/test-unset-trace2-parents: test-lib: unset trace2 parent envvars
2022-02-05The first batchLibravatar Junio C Hamano1-3/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-05Merge branch 'ms/update-index-racy'Libravatar Junio C Hamano6-6/+135
"git update-index --refresh" has been taught to deal better with racy timestamps (just like "git status" already does). * ms/update-index-racy: update-index: refresh should rewrite index in case of racy timestamps t7508: add tests capturing racy timestamp handling t7508: fix bogus mtime verification test-lib: introduce API for verifying file mtime
2022-02-05Merge branch 'jc/reflog-parse-options'Libravatar Junio C Hamano1-79/+97
Use the parse-options API in "git reflog" command. * jc/reflog-parse-options: builtin/reflog.c: use parse-options api for expire, delete subcommands
2022-02-05Merge branch 'ab/cat-file'Libravatar Junio C Hamano9-80/+282
Assorted updates to "git cat-file", especially "-h". * ab/cat-file: cat-file: s/_/-/ in typo'd usage_msg_optf() message cat-file: don't whitespace-pad "(...)" in SYNOPSIS and usage output cat-file: use GET_OID_ONLY_TO_DIE in --(textconv|filters) object-name.c: don't have GET_OID_ONLY_TO_DIE imply *_QUIETLY cat-file: correct and improve usage information cat-file: fix remaining usage bugs cat-file: make --batch-all-objects a CMDMODE cat-file: move "usage" variable to cmd_cat_file() cat-file docs: fix SYNOPSIS and "-h" output parse-options API: add a usage_msg_optf() cat-file tests: test messaging on bad objects/paths cat-file tests: test bad usage
2022-02-05Merge branch 'jc/qsort-s-alignment-fix'Libravatar Junio C Hamano2-21/+9
Fix a hand-rolled alloca() imitation that may have violated alignment requirement of data being sorted in compatibility implementation of qsort_s() and stable qsort(). * jc/qsort-s-alignment-fix: stable-qsort: avoid using potentially unaligned access compat/qsort_s.c: avoid using potentially unaligned access
2022-02-05Merge branch 'rs/apply-symlinks-use-strset'Libravatar Junio C Hamano2-49/+19
"git apply" (ab)used the util pointer of the string-list to keep track of how each symbolic link needs to be handled, which has been simplified by using strset. * rs/apply-symlinks-use-strset: apply: use strsets to track symlinks
2022-02-05Merge branch 'rs/grep-expr-cleanup'Libravatar Junio C Hamano1-34/+36
Code clean-up. * rs/grep-expr-cleanup: grep: use grep_and_expr() in compile_pattern_and() grep: extract grep_binexp() from grep_or_expr() grep: use grep_not_expr() in compile_pattern_not() grep: use grep_or_expr() in compile_pattern_or()
2022-02-05Merge branch 'jh/p4-spawning-external-commands-cleanup'Libravatar Junio C Hamano1-97/+79
* jh/p4-spawning-external-commands-cleanup: git-p4: don't print shell commands as python lists git-p4: pass command arguments as lists instead of using shell git-p4: don't select shell mode using the type of the command argument
2022-02-05Merge branch 'jh/p4-fix-use-of-process-error-exception'Libravatar Junio C Hamano1-3/+3
* jh/p4-fix-use-of-process-error-exception: git-p4: fix instantiation of CalledProcessError
2022-02-05Merge branch 'jc/find-header'Libravatar Junio C Hamano3-25/+29
Code clean-up. * jc/find-header: receive-pack.c: consolidate find header logic
2022-02-05Merge branch 'pb/pull-rebase-autostash-fix'Libravatar Junio C Hamano2-4/+16
"git pull --rebase" ignored the rebase.autostash configuration variable when the remote history is a descendant of our history, which has been corrected. * pb/pull-rebase-autostash-fix: pull --rebase: honor rebase.autostash when fast-forwarding
2022-01-28Sync with Git 2.35.1Libravatar Junio C Hamano1-0/+6
2022-01-28Name the next one 2.36 to prepare for 2.35.1Libravatar Junio C Hamano2-1/+35
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28Git 2.35.1Libravatar Junio C Hamano3-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28Merge branch 'en/keep-cwd' into maintLibravatar Junio C Hamano3-2/+30
Fix a regression in 2.35 that roke the use of "rebase" and "stash" in a secondary worktree. * en/keep-cwd: sequencer, stash: fix running from worktree subdir
2022-01-26Merge branch 'en/keep-cwd'Libravatar Junio C Hamano3-2/+30
Fix a regression in 2.35 that roke the use of "rebase" and "stash" in a secondary worktree. * en/keep-cwd: sequencer, stash: fix running from worktree subdir
2022-01-26Start post 2.35 cycleLibravatar Junio C Hamano1-1/+1
The tree is not open for new development yet, but let's mark the beginning of the new cycle before we start merging down regression fix topics. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26sequencer, stash: fix running from worktree subdirLibravatar Elijah Newren3-2/+30
In commits bc3ae46b42 ("rebase: do not attempt to remove startup_info->original_cwd", 2021-12-09) and 0fce211ccc ("stash: do not attempt to remove startup_info->original_cwd", 2021-12-09), we wanted to allow the subprocess to know which directory the parent process was running from, so that the subprocess could protect it. However... When run from a non-main worktree, setup_git_directory() will note that the discovered git directory (/PATH/TO/.git/worktree/non-main-worktree) does not match DEFAULT_GIT_DIR_ENVIRONMENT (see setup_discovered_git_dir()), and decide to set GIT_DIR in the environment. This matters because... Whenever git is run with the GIT_DIR environment variable set, and GIT_WORK_TREE not set, it presumes that '.' is the working tree. So... This combination results in the subcommand being very confused about the working tree. Fix it by also setting the GIT_WORK_TREE environment variable along with setting cmd.dir. A possibly more involved fix we could consider for later would be to make setup.c set GIT_WORK_TREE whenever (a) it discovers both the git directory and the working tree and (b) it decides to set GIT_DIR in the environment. I did not attempt that here as such would be too big of a change for a 2.35.1 release. Test-case-by: Glen Choo <chooglen@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26clone: support unusual remote ref configurationsLibravatar Jonathan Tan2-6/+21
When cloning a branchless and tagless but not refless remote using protocol v0 or v1, Git calls transport_fetch_refs() with an empty ref list. This makes the clone fail with the message "remote transport reported error". Git should have refrained from calling transport_fetch_refs(), just like it does in the case that the remote is refless. Therefore, teach Git to do this. In protocol v2, this does not happen because the client passes ref-prefix arguments that filter out non-branches and non-tags in the ref advertisement, making the remote appear empty. Note that this bug concerns logic in builtin/clone.c and only affects cloning, not fetching. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24mem-pool: don't assume uintmax_t is aligned enough for all typesLibravatar Jessica Clarke1-3/+23
mem_pool_alloc uses sizeof(uintmax_t) as a proxy for what should be _Alignof(max_align_t) in C11. On most architectures this is sufficient (though on m68k it is in fact overly strict, since the de-facto ABI, which differs from the specified System V ABI, has the maximum alignment of all types as 2 bytes), but on CHERI, and thus Arm's Morello prototype, it is insufficient for any type that stores a pointer, which must be aligned to 128 bits (on 64-bit architectures extended with CHERI), whilst uintmax_t is a 64-bit integer. Fix this by introducing our own approximation for max_align_t and a means to compute _Alignof it without relying on C11. Currently this union only contains uintmax_t and void *, but more types can be added as needed. Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24Git 2.35Libravatar Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24Merge branch 'ab/checkout-branch-info-leakfix'Libravatar Junio C Hamano2-3/+13
We added an unrelated sanity checking that leads to a BUG() while plugging a leak, which triggered in a repository with symrefs in the local branch namespace that point at a ref outside. Partially revert the change to avoid triggering the BUG(). * ab/checkout-branch-info-leakfix: checkout: avoid BUG() when hitting a broken repository
2022-01-24Merge tag 'l10n-2.35.0-rnd2' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano11-39598/+36951
l10n-2.35.0-rnd2 * tag 'l10n-2.35.0-rnd2' of git://github.com/git-l10n/git-po: l10n: Update Catalan translation l10n: zh_TW: v2.35.0 round 2 (0 untranslated) l10n: Update Catalan translation l10n: de.po: Update German translation l10n: de.po: Fix translation for "'%s' is aliased to '%s'" l10n: po-id for 2.35 (round 2) l10n: Update Catalan translation l10n: vi(5195t): Update for v2.35.0 round 2 l10n: batch update to fix typo in branch.c l10n: git.pot: v2.35.0 round 2 (1 new, 1 removed) l10n: bg.po: Updated Bulgarian translation (5195t) l10n: zh_CN: v2.35.0 round 1 l10n: fr: v2.35.0 round 1 l10n: zh_TW: v2.35.0 round 1 (1 fuzzy) l10n: po-id for 2.35 (round 1) l10n: sv.po: Update Swedish translation (5196t0f0u) l10n: sv.po: Fix typo l10n: tr: v2.35.0 round 1 l10n: git.pot: v2.35.0 round 1 (126 new, 142 removed)
2022-01-23split-index: it really is incompatible with the sparse indexLibravatar Johannes Schindelin2-0/+6
... at least for now. So let's error out if we are even trying to initialize the split index when the index is sparse, or when trying to write the split index extension for a sparse index. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-23t1091: disable split indexLibravatar Johannes Schindelin1-28/+26
In 61feddcdf28 (tests: disable GIT_TEST_SPLIT_INDEX for sparse index tests, 2021-08-26), it was already called out that the split index feature is incompatible with the sparse index feature, and its commit message wondered aloud whether more checks would be required to ensure that the split index and sparse index features aren't enabled at the same time. We are about to introduce such additional checks, and indeed, t1091 would utterly fail with them. Therefore, let's preemptively disable the split index for the entirety of t1091. This partially reverts above-mentioned patch because it covered only one test case whereas we want to cover the entire test script. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-23sparse-index: sparse index is disallowed when split index is activeLibravatar Johannes Schindelin1-1/+1
In 6e773527b6b (sparse-index: convert from full to sparse, 2021-03-30), we introduced initial support for a sparse index, and were careful to avoid converting to a sparse index in the presence of a split index. However, when we _just_ read a freshly-initialized index, it might not contain a split index even if _writing_ it will add one by virtue of being asked for via the `GIT_TEST_SPLIT_INDEX` variable. We did not notice any problems with checking _only_ for `split_index` (and not `GIT_TEST_SPLIT_INDEX`) right until both `vd/sparse-sparsity-fix-on-read` _and_ `vd/sparse-reset` were merged. Those two topics' interplay triggers a bug in conjunction with running t1091.15 when `GIT_TEST_SPLIT_INDEX=true` in the following way: `vd/sparse-sparsity-fix-on-read` ensures that the index is made sparse right after reading, and `vd/sparse-reset` ensures that the index is made non-sparse again unless running in the `--soft` mode. Since the split index feature is incompatible with the sparse index feature, we see a symptom like this: fatal: position for replacement 4 exceeds base index size 4 Let's fix this by avoiding the conversion to a sparse index when `GIT_TEST_SPLIT_INDEX=true`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-23l10n: Update Catalan translationLibravatar Jordi Mas1-16/+16
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2022-01-22Merge branch 'l10n/zh_TW/220113' of github.com:l10n-tw/git-poLibravatar Jiang Xin1-3115/+3462
* 'l10n/zh_TW/220113' of github.com:l10n-tw/git-po: l10n: zh_TW: v2.35.0 round 2 (0 untranslated) l10n: zh_TW: v2.35.0 round 1 (1 fuzzy)
2022-01-21checkout: avoid BUG() when hitting a broken repositoryLibravatar Junio C Hamano2-3/+13
When 9081a421 (checkout: fix "branch info" memory leaks, 2021-11-16) cleaned up existing memory leaks, we added an unrelated sanity check to ensure that a local branch is truly local and not a symref to elsewhere that dies with BUG() otherwise. This was misguided in two ways. First of all, such a tightening did not belong to a leak-fix patch. And the condition it detected was *not* a bug in our program but a problem in user data, where warning() or die() would have been more appropriate. As the condition is not fatal (the result of computing the local branch name in the code that is involved in the faulty check is only used as a textual label for the commit), let's revert the code to the original state, i.e. strip "refs/heads/" to compute the local branch name if possible, and otherwise leave it NULL. The consumer of the information in merge_working_tree() is prepared to see NULL in there and act accordingly. cf. https://bugzilla.redhat.com/show_bug.cgi?id=2042920 Reported-by: Petr Šplíchal <psplicha@redhat.com> Reported-by: Todd Zullinger <tmz@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-21merge: fix memory leaks in cmd_merge()Libravatar Elijah Newren1-1/+5
There were two commit_lists created in cmd_merge() that were only conditionally free()'d. Add a quick conditional call to free_commit_list() for each of them at the end of the function. Testing this commit against t6404 under valgrind shows that this patch fixes the following two leaks: 16 bytes in 1 blocks are definitely lost in loss record 16 of 126 at 0x484086F: malloc (vg_replace_malloc.c:380) by 0x69FFEB: do_xmalloc (wrapper.c:41) by 0x6A0073: xmalloc (wrapper.c:62) by 0x52A72D: commit_list_insert (commit.c:556) by 0x47FC93: reduce_parents (merge.c:1114) by 0x4801EE: collect_parents (merge.c:1214) by 0x480B56: cmd_merge (merge.c:1465) by 0x40686E: run_builtin (git.c:464) by 0x406C51: handle_builtin (git.c:716) by 0x406E96: run_argv (git.c:783) by 0x40730A: cmd_main (git.c:914) by 0x4E7DFA: main (common-main.c:56) 8 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in \ loss record 61 of 126 at 0x484086F: malloc (vg_replace_malloc.c:380) by 0x69FFEB: do_xmalloc (wrapper.c:41) by 0x6A0073: xmalloc (wrapper.c:62) by 0x52A72D: commit_list_insert (commit.c:556) by 0x52A8F2: commit_list_insert_by_date (commit.c:620) by 0x5270AC: get_merge_bases_many_0 (commit-reach.c:413) by 0x52716C: repo_get_merge_bases (commit-reach.c:438) by 0x480E5A: cmd_merge (merge.c:1520) by 0x40686E: run_builtin (git.c:464) by 0x406C51: handle_builtin (git.c:716) by 0x406E96: run_argv (git.c:783) by 0x40730A: cmd_main (git.c:914) There are still 3 leaks in chdir_notify_register() after this, but chdir_notify_register() has been brought up on the list before and folks were not a fan of fixing those, so I'm not touching them. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-21merge-ort: fix memory leak in merge_ort_internal()Libravatar Elijah Newren1-5/+5
The documentation for merge_incore_recursive(), modelled after merge_recursive(), notes that merge_bases will be consumed (emptied) so make a copy if you need it However, in merge_ort_internal() (which merge_incore_recursive() calls), it runs merged_merge_bases = pop_commit(&merge_bases); ... for (iter = merge_bases; iter; iter = iter->next) { ... } In other words, it only consumes the *first* entry of merge_bases, and the rest it iterates through. If it iterated through all of them, the caller could be responsible for free'ing the memory. If it consumed all of them, the current documentation would be correct and the callers would need to do nothing. The current middle ground makes it impossible for callers to avoid memory leaks, since any attempt to use the merge_bases it passes in would result in a use-after-free. It turns out this part of the code was copied from merge-recursive.c, which has had the same bug for 15.5 years. However, since we are trying to keep merge-recursive.c stable as we sunset it, let's just fix the leak in in merge_ort_internal() by having it actually consume all the elements of the merge_bases commit_list. Testing this commit against t6404 (the first testcase specifically about recursive merges) under valgrind shows that this patch fixes the following leak: 32 (16 direct, 16 indirect) bytes in 1 blocks are definitely lost \ in loss record 49 of 126 at 0x484086F: malloc (vg_replace_malloc.c:380) by 0x69FFEB: do_xmalloc (wrapper.c:41) by 0x6A0073: xmalloc (wrapper.c:62) by 0x52A72D: commit_list_insert (commit.c:556) by 0x47EC86: try_merge_strategy (merge.c:751) by 0x48143B: cmd_merge (merge.c:1679) by 0x40686E: run_builtin (git.c:464) by 0x406C51: handle_builtin (git.c:716) by 0x406E96: run_argv (git.c:783) by 0x40730A: cmd_main (git.c:914) by 0x4E7DFA: main (common-main.c:56) Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>