summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-08-02Git 2.33-rc0Libravatar Junio C Hamano2-1/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-02Merge branch 'jk/check-pack-valid-before-opening-bitmap'Libravatar Junio C Hamano1-0/+5
A race between repacking and using pack bitmaps has been corrected. * jk/check-pack-valid-before-opening-bitmap: pack-bitmap: check pack validity when opening bitmap
2021-08-02Merge branch 'jt/bulk-prefetch'Libravatar Junio C Hamano5-21/+82
"git read-tree" had a codepath where blobs are fetched one-by-one from the promisor remote, which has been corrected to fetch in bulk. * jt/bulk-prefetch: cache-tree: prefetch in partial clone read-tree unpack-trees: refactor prefetching code
2021-08-02Merge branch 'fc/pull-no-rebase-merges-theirs-into-ours'Libravatar Junio C Hamano1-1/+1
Documentation fix for "git pull --rebase=no". * fc/pull-no-rebase-merges-theirs-into-ours: doc: pull: fix rebase=false documentation
2021-08-02Merge branch 'ab/bundle-tests'Libravatar Junio C Hamano1-16/+56
"git bundle" gained more test coverage. * ab/bundle-tests: bundle tests: use test_cmp instead of grep bundle tests: use ">file" not ": >file"
2021-08-02Merge branch 'ps/perf-with-separate-output-directory'Libravatar Junio C Hamano3-13/+24
Test update. * ps/perf-with-separate-output-directory: perf: fix when running with TEST_OUTPUT_DIRECTORY
2021-08-02Merge branch 'js/ci-check-whitespace-updates'Libravatar Junio C Hamano1-24/+2
CI update. * js/ci-check-whitespace-updates: ci(check-whitespace): restrict to the intended commits ci(check-whitespace): stop requiring a read/write token
2021-08-02Merge branch 'jk/config-env-doc'Libravatar Junio C Hamano1-11/+17
Documentation around GIT_CONFIG has been updated. * jk/config-env-doc: doc/git-config: simplify "override" advice for FILES section doc/git-config: clarify GIT_CONFIG environment variable doc/git-config: explain --file instead of referring to GIT_CONFIG
2021-08-02Merge branch 'pb/submodule-recurse-doc'Libravatar Junio C Hamano1-2/+3
Doc update. * pb/submodule-recurse-doc: doc: clarify description of 'submodule.recurse'
2021-08-02Merge branch 'tb/bitmap-type-filter-comment-fix'Libravatar Junio C Hamano1-5/+6
In-code comment update. * tb/bitmap-type-filter-comment-fix: pack-bitmap: clarify comment in filter_bitmap_exclude_type()
2021-07-28The seventh batchLibravatar Junio C Hamano1-0/+43
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-28Merge branch 'ps/t0000-output-directory-fix'Libravatar Junio C Hamano2-2/+14
"TEST_OUTPUT_DIRECTORY=there make test" failed to work, which has been corrected. * ps/t0000-output-directory-fix: t0000: fix test if run with TEST_OUTPUT_DIRECTORY
2021-07-28Merge branch 'tb/reverse-midx'Libravatar Junio C Hamano2-1/+6
The code that gives an error message in "git multi-pack-index" when no subcommand is given tried to print a NULL pointer as a strong, which has been corrected. * tb/reverse-midx: multi-pack-index: fix potential segfault without sub-command
2021-07-28Merge branch 'hn/refs-debug-empty-prefix'Libravatar Junio C Hamano1-1/+2
Debugging aid. * hn/refs-debug-empty-prefix: refs/debug: quote prefix
2021-07-28Merge branch 'pb/dont-complete-aliased-options'Libravatar Junio C Hamano2-1/+14
The completion support used to offer alternate spelling of options that exist only for compatibility, which has been corrected. * pb/dont-complete-aliased-options: parse-options: don't complete option aliases by default
2021-07-28Merge branch 'en/rename-limits-doc'Libravatar Junio C Hamano7-17/+26
Documentation on "git diff -l<n>" and diff.renameLimit have been updated, and the defaults for these limits have been raised. * en/rename-limits-doc: rename: bump limit defaults yet again diffcore-rename: treat a rename_limit of 0 as unlimited doc: clarify documentation for rename/copy limits diff: correct warning message when renameLimit exceeded
2021-07-28Merge branch 'ds/gender-neutral-doc-guidelines'Libravatar Junio C Hamano1-0/+45
A guideline for gender neutral documentation has been added. * ds/gender-neutral-doc-guidelines: CodingGuidelines: recommend gender-neutral description
2021-07-28Merge branch 'ds/status-with-sparse-index'Libravatar Junio C Hamano10-38/+470
"git status" codepath learned to work with sparsely populated index without hydrating it fully. * ds/status-with-sparse-index: t1092: document bad sparse-checkout behavior fsmonitor: integrate with sparse index wt-status: expand added sparse directory entries status: use sparse-index throughout status: skip sparse-checkout percentage with sparse-index diff-lib: handle index diffs with sparse dirs dir.c: accept a directory as part of cone-mode patterns unpack-trees: unpack sparse directory entries unpack-trees: rename unpack_nondirectories() unpack-trees: compare sparse directories correctly unpack-trees: preserve cache_bottom t1092: add tests for status/add and sparse files t1092: expand repository data shape t1092: replace incorrect 'echo' with 'cat' sparse-index: include EXTENDED flag when expanding sparse-index: skip indexes with unmerged entries
2021-07-28Merge branch 'js/ci-make-sparse'Libravatar Junio C Hamano2-0/+25
The CI gained a new job to run "make sparse" check. * js/ci-make-sparse: ci/install-dependencies: handle "sparse" job package installs ci: run "apt-get update" before "apt-get install" ci: run `make sparse` as part of the GitHub workflow
2021-07-28Merge branch 'ab/pkt-line-tests'Libravatar Junio C Hamano5-34/+24
Tests that cover protocol bits have been updated and helpers used there have been consolidated. * ab/pkt-line-tests: test-lib-functions: use test-tool for [de]packetize()
2021-07-28Merge branch 'jk/t0000-subtests-fix'Libravatar Junio C Hamano1-10/+29
Test fix. * jk/t0000-subtests-fix: t0000: clear GIT_SKIP_TESTS before running sub-tests
2021-07-28Merge branch 'dl/diff-merge-base'Libravatar Junio C Hamano2-5/+9
"git diff --merge-base" documentation has been updated. * dl/diff-merge-base: git-diff: fix missing --merge-base docs
2021-07-28Merge branch 'ab/attribute-format'Libravatar Junio C Hamano23-29/+47
Many "printf"-like helper functions we have have been annotated with __attribute__() to catch placeholder/parameter mismatches. * ab/attribute-format: advice.h: add missing __attribute__((format)) & fix usage *.h: add a few missing __attribute__((format)) *.c static functions: add missing __attribute__((format)) sequencer.c: move static function to avoid forward decl *.c static functions: don't forward-declare __attribute__
2021-07-28Merge branch 'jk/log-decorate-optim'Libravatar Junio C Hamano8-32/+77
Optimize "git log" for cases where we wasted cycles to load ref decoration data that may not be needed. * jk/log-decorate-optim: load_ref_decorations(): fix decoration with tags add_ref_decoration(): rename s/type/deco_type/ load_ref_decorations(): avoid parsing non-tag objects object.h: add lookup_object_by_type() function object.h: expand docstring for lookup_unknown_object() log: avoid loading decorations for userformats that don't need it pretty.h: update and expand docstring for userformat_find_requirements()
2021-07-28Merge branch 'sm/worktree-add-lock'Libravatar Junio C Hamano3-8/+33
"git worktree add --lock" learned to record why the worktree is locked with a custom message. * sm/worktree-add-lock: worktree: teach `add` to accept --reason <string> with --lock worktree: mark lock strings with `_()` for translation t2400: clean up '"add" worktree with lock' test
2021-07-28Merge branch 'ew/many-alternate-optim'Libravatar Junio C Hamano16-51/+534
Optimization for repositories with many alternate object store. * ew/many-alternate-optim: oidtree: a crit-bit tree for odb_loose_cache oidcpy_with_padding: constify `src' arg make object_directory.loose_objects_subdir_seen a bitmap avoid strlen via strbuf_addstr in link_alt_odb_entry speed up alt_odb_usable() with many alternates
2021-07-28Merge branch 'hj/commit-allow-empty-message'Libravatar Junio C Hamano2-12/+19
"git commit --allow-empty-message" won't abort the operation upon an empty message, but the hint shown in the editor said otherwise. * hj/commit-allow-empty-message: commit: remove irrelavent prompt on `--allow-empty-message` commit: reorganise commit hint strings
2021-07-28Merge branch 'dl/packet-read-response-end-fix'Libravatar Junio C Hamano3-3/+3
Error message update. * dl/packet-read-response-end-fix: pkt-line: replace "stateless separator" with "response end"
2021-07-26ci/install-dependencies: handle "sparse" job package installsLibravatar Jeff King2-4/+7
This just matches the style/location of the package installation for other jobs. There should be no functional change. I did flip the order of the options and command-name ("-y update" instead of "update -y") for consistency with other lines in the same file. Note also that we have to reorder the dependency install with the "checkout" action, so that we actually have the "ci" scripts available. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-26ci: run "apt-get update" before "apt-get install"Libravatar Jeff King1-0/+1
The "sparse" workflow runs "apt-get install" to pick up a few necessary packages. But it needs to run "apt-get update" first, or it risks trying to download an old package version that no longer exists. And in fact this happens now, with output like: 2021-07-26T17:40:51.2551880Z E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl4-openssl-dev_7.68.0-1ubuntu2.5_amd64.deb 404 Not Found [IP: 52.147.219.192 80] 2021-07-26T17:40:51.2554304Z E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Our other ci jobs don't suffer from this; they rely on scripts in ci/, and ci/install-dependencies does the appropriate "apt-get update". Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-23cache-tree: prefetch in partial clone read-treeLibravatar Jonathan Tan2-2/+42
"git read-tree" checks the existence of the blobs referenced by the given tree, but does not bulk prefetch them. Add a bulk prefetch. The lack of prefetch here was noticed at $DAYJOB during a merge involving some specific commits, but I couldn't find a minimal merge that didn't also trigger the prefetch in check_updates() in unpack-trees.c (and in all these cases, the lack of prefetch in cache-tree.c didn't matter because all the relevant blobs would have already been prefetched by then). This is why I used read-tree here to exercise this code path. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-23unpack-trees: refactor prefetching codeLibravatar Jonathan Tan3-19/+40
Refactor the prefetching code in unpack-trees.c into its own function, because it will be used elsewhere in a subsequent commit. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-23pack-bitmap: check pack validity when opening bitmapLibravatar Jeff King1-0/+5
When pack-objects adds an entry to its list of objects to pack, it may mark the packfile and offset that contains the file, which we can later use to output the object verbatim. If the packfile is deleted while we are running (e.g., by another process running "git repack"), we may die in use_pack() if the pack file cannot be opened. We worked around this in 4c08018204 (pack-objects: protect against disappearing packs, 2011-10-14) by making sure we can open the pack before recording it as a source. This detects a pack which has already disappeared while generating the packing list, and because we keep the pack's file descriptor (or an mmap window) open, it means we can access it later (unless you exceed core.packedgitlimit). The bitmap code that was added later does not do this; it adds entries to the packlist without checking that the packfile is still valid, and is vulnerable to this race. It needs the same treatment as 4c08018204. However, rather than add it in just that one spot, it makes more sense to simply open and check the packfile when we open the bitmap. Technically you can use the .bitmap without even looking in the .pack file (e.g., if you are just printing a list of objects without accessing them), but it's much simpler to do it early. That covers all later direct uses of the pack (due to the cached descriptor) without having to check each one directly. For example, in pack-objects we need to protect the packlist entries, but we also access the pack directly as part of the reuse_partial_pack_from_bitmap() feature. This patch covers both cases. There's no test here, because the problem is inherently racy. I reproduced and verified the fix with this script: rm -rf parent.git push.git fetch.git push() { ( cd push.git && echo content >>file && git add file && git commit -qm "change $1" && git push -q origin HEAD && echo "push $1..." ) && ( cd parent.git && git repack -ad -q && echo "repack $1..." ) } fetch() { rm -rf fetch.git && git clone -q file://$PWD/parent.git fetch.git && echo "fetch $1..." } git init --bare parent.git && git --git-dir=parent.git config transfer.unpacklimit 1 && git clone parent.git push.git && (for i in `seq 1 1000`; do push $i || break; done) & pusher=$! (for i in `seq 1 1000`; do fetch $i || break; done) & fetcher=$! wait $fetcher kill $pusher That simulates a race between a client cloning and a push triggering a repack on the server. Without this patch, it generally fails within a couple hundred iterations with: remote: fatal: packfile ./objects/pack/.tmp-1377349-pack-498afdec371232bdb99d1757872f5569331da61e.pack cannot be accessed error: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: fetch-pack: invalid index-pack output With this patch, it reliably runs through all thousand attempts. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22bundle tests: use test_cmp instead of grepLibravatar Ævar Arnfjörð Bjarmason1-13/+53
Change the bundle tests to fully compare the expected "git ls-remote" or "git bundle list-heads" output, instead of merely grepping it. This avoids subtle regressions in the tests. In f62e0a39b6 (t5704 (bundle): add tests for bundle --stdin, 2010-04-19) the "bundle --stdin <rev-list options>" test was added to make sure we didn't include the tag. But since the --stdin mode didn't work until 5bb0fd2cab (bundle: arguments can be read from stdin, 2021-01-11) our grepping of "master" (later "main") missed the important part of the test. Namely that we should not include the "refs/tags/tag" tag in that case. Since the test only grepped for "main" in the output we'd miss a regression in that code. So let's use test_cmp instead, and also in the other nearby tests where it's easy. This does make things a bit more verbose in the case of the test that's checking the bundle header, since it's different under SHA1 and SHA256. I think this makes test easier to follow. I've got some WIP changes to extend the "git bundle" command to dump parts of the header out, which are easier to understand if we test the output explicitly like this. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22bundle tests: use ">file" not ": >file"Libravatar Ævar Arnfjörð Bjarmason1-3/+3
Change uses of ":" on the LHS of a ">" to the more commonly used ">file" pattern in t/t5607-clone-bundle.sh. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22The sixth batchLibravatar Junio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22Merge branch 'bc/rev-list-without-commit-line'Libravatar Junio C Hamano4-12/+112
"git rev-list" learns to omit the "commit <object-name>" header lines from the output with the `--no-commit-header` option. * bc/rev-list-without-commit-line: rev-list: add option for --pretty=format without header
2021-07-22Merge branch 'ab/imap-send-read-everything-simplify'Libravatar Junio C Hamano1-14/+2
Code simplification. * ab/imap-send-read-everything-simplify: imap-send.c: use less verbose strbuf_fread() idiom
2021-07-22Merge branch 'ab/gitignore-discovery-doc'Libravatar Junio C Hamano1-6/+5
Doc update. * ab/gitignore-discovery-doc: docs: .gitignore parsing is to the top of the repo
2021-07-22Merge branch 'js/ci-windows-update'Libravatar Junio C Hamano2-112/+50
GitHub Actions / CI update. * js/ci-windows-update: ci: accelerate the checkout ci (vs-build): build with NO_GETTEXT artifacts-tar: respect NO_GETTEXT ci (windows): transfer also the Git-tracked files to the test jobs ci: upgrade to using actions/{up,down}load-artifacts v2 ci (vs-build): use `cmd` to copy the DLLs, not `powershell` ci: use the new GitHub Action to download git-sdk-64-minimal
2021-07-22Merge branch 'ab/send-email-optim'Libravatar Junio C Hamano4-79/+159
"git send-email" optimization. * ab/send-email-optim: perl: nano-optimize by replacing Cwd::cwd() with Cwd::getcwd() send-email: move trivial config handling to Perl perl: lazily load some common Git.pm setup code send-email: lazily load modules for a big speedup send-email: get rid of indirect object syntax send-email: use function syntax instead of barewords send-email: lazily shell out to "git var" send-email: lazily load config for a big speedup send-email: copy "config_regxp" into git-send-email.perl send-email: refactor sendemail.smtpencryption config parsing send-email: remove non-working support for "sendemail.smtpssl" send-email tests: test for boolean variables without a value send-email tests: support GIT_TEST_PERL_FATAL_WARNINGS=true
2021-07-22Merge branch 'jk/typofix'Libravatar Junio C Hamano1-1/+1
Typofix. * jk/typofix: doc/rev-list-options: fix duplicate word typo
2021-07-21doc: pull: fix rebase=false documentationLibravatar Felipe Contreras1-1/+1
"git pull --rebase=false" means we merge their history into ours, but it has been described the other way around. Cc: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> [jc: updated the log message] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20pack-bitmap: clarify comment in filter_bitmap_exclude_type()Libravatar Taylor Blau1-5/+6
The code that eventually became filter_bitmap_exclude_type() was originally introduced in 4f3bd5606a (pack-bitmap: implement BLOB_NONE filtering, 2020-02-14) to accelerate BLOB_NONE filters with bitmaps. In 856e12c18a (pack-bitmap.c: make object filtering functions generic, 2020-05-04), it became filter_bitmap_exclude_type(). But not all of the comments were updated to be agnostic to the provided type. Remove the remaining comments which should have been updated in 856e12c18a to reflect the type-agnostic nature of the function. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20doc: clarify description of 'submodule.recurse'Libravatar Philippe Blain1-2/+3
The doc for 'submodule.recurse' starts with "Specifies if commands recurse into submodles by default". This is not exactly true of all commands that have a '--recurse-submodules' option. For example, 'git pull --recurse-submodules' does not run 'git pull' in each submodule, but rather runs 'git submodule update --recursive' so that the submodule working trees after the pull matches the commits recorded in the superproject. Clarify that by just saying that it enables '--recurse-submodules'. Note that the way this setting interacts with 'fetch.recurseSubmodules' and 'push.recurseSubmodules', which can have other values than true or false, is already documented since 4da9e99e6e (doc: be more precise on (fetch|push).recurseSubmodules, 2020-04-06). Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20doc/git-config: simplify "override" advice for FILES sectionLibravatar Jeff King1-5/+4
At the end of the FILES section, we indicate that you can override the regular lookup rules with --global, etc. But: - we're missing the --local option - we point to GIT_CONFIG instead of --file, but the latter has much better documentation - we're vague about how the overrides work; the actual option descriptions are much better here So let's just mention the names and point people back to the OPTIONS section. We could perhaps even delete this paragraph entirely, but the presence of the names may give people reading FILES a clue about where to look for more information. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20doc/git-config: clarify GIT_CONFIG environment variableLibravatar Jeff King1-5/+6
The scope and utility of the GIT_CONFIG variable was drastically reduced by dc87183189 (Only use GIT_CONFIG in "git config", not other programs, 2008-06-30). But the documentation in git-config(1) predates that, which makes it rather misleading. These days it is really just another way to say "--file". So let's say that, and explicitly make it clear that it does not impact other Git commands (like GIT_CONFIG_SYSTEM, etc, would). I also bumped it to the bottom of the list of variables, and warned people off of using it. We don't have any plans for deprecation at this point, but there's little point in encouraging people to use it by putting it at the top of the list. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20doc/git-config: explain --file instead of referring to GIT_CONFIGLibravatar Jeff King1-1/+7
The explanation for the --file option only refers to GIT_CONFIG. This redirection to an environment variable is confusing, but doubly so because the description of GIT_CONFIG is out of date. Let's describe --file from scratch, detailing both the reading and writing behavior as we do for other similar options like --system, etc. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20t0000: fix test if run with TEST_OUTPUT_DIRECTORYLibravatar Patrick Steinhardt2-2/+14
Testcases in t0000 are quite special given that they many of them run nested testcases to verify that testing functionality itself works as expected. These nested testcases are realized by writing a new ad-hoc test script which again sources test-lib.sh, where the new script is created in a nested subdirectory located beneath the current trash directory. We then execute the new test script with the nested subdirectory as current working directory and explicitly re-export TEST_OUTPUT_DIRECTORY to point to that directory. While this works as expected in the general case, it falls apart when the developer has TEST_OUTPUT_DIRECTORY explicitly defined either via the environment or via config.mak and runs "make test". In that case, test-lib.sh will clobber the value that we've just carefully set up to instead contain what the developer has defined. As a result, the TEST_OUTPUT_DIRECTORY continues to point at the root output directory, not at the nested one. This issue causes breakage in the 'test_atexit is run' test case: the nested test case writes files into "../../", which is assumed to be the parent's trash directory. But because TEST_OUTPUT_DIRECTORY already points to to the root output directory, we instead end up writing those files outside of the output directory. The parent test case will then try to check whether those files still exist in its own trash directory, which thus must fail now. Fix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable. If set, then we'll always override the TEST_OUTPUT_DIRECTORY with its value after sourcing GIT-BUILD-OPTIONS. Signed-off-by: Patrick Steinhardt <ps@pks.im> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-19multi-pack-index: fix potential segfault without sub-commandLibravatar Taylor Blau2-1/+6
Since cd57bc41bb (builtin/multi-pack-index.c: display usage on unrecognized command, 2021-03-30) we have used a "usage" label to avoid having two separate callers of usage_with_options (one when no arguments are given, and another for unrecognized sub-commands). But the first caller has been broken since cd57bc41bb, since it will happily jump to usage without arguments, and then pass argv[0] to the "unrecognized subcommand" error. Many compilers will save us from a segfault here, but the end result is ugly, since it mentions an unrecognized subcommand when we didn't even pass one, and (on GCC) includes "(null)" in its output. Move the "usage" label down past the error about unrecognized subcommands so that it is only triggered when it should be. While we're at it, bulk up our test coverage in this area, too. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>