No need to memcpy() source buffer data when we might just process the
data in place instead of accumulating it into a separate buffer.
This is the case when a whole buffer would have been copied, summed,
written out and then discarded right away.
Also move the CRC32 processing within the loop so the data is more likely
to remain in the L1 CPU cache between the CRC32 sum, SHA1 sum and the
write call.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* np/maint-safer-pack:
fixup_pack_header_footer(): use nicely aligned buffer sizes
index-pack: use fixup_pack_header_footer()'s validation mode
pack-objects: use fixup_pack_header_footer()'s validation mode
improve reliability of fixup_pack_header_footer()
pack-objects: improve returned information from write_one()
The SYNOPSIS section of gitattibutes and gitmodule fail to clearly
specify the name of the in tree files used. This patch brings in the
initial `.' and the fact that the `.gitmodules' file should reside at
the top-level of the working tree.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
gitattributes: -crlf is not binary
git-apply: Loosen "match_beginning" logic
Fix example in git-name-rev documentation
shell: do not play duplicated definition games to shrink the executable
Fix use of hardlinks in "make install"
pack-objects: Allow missing base objects when creating thin packs
The description of crlf attribute incorrectly said that "-crlf" means
binary. It is true that for binary files you would want "-crlf", but
that is not the same thing.
We also have supported attribute macros and via that mechanism a handy
"binary" to specify "-crlf -diff" at the same time. It was not documented
anywhere as far as I can tell, even though the support was there from
the very beginning.
Even after a handfle attempts, match_beginning logic still has corner
cases:
1bf1a85 (apply: treat EOF as proper context., 2006-05-23) 65aadb9 (apply: force matching at the beginning., 2006-05-24) 4be6096 (apply --unidiff-zero: loosen sanity checks ..., 2006-09-17) ee5a317 (Fix "git apply" to correctly enforce "match ..., 2008-04-06)
This is a tricky piece of code.
We still incorrectly enforce "match_beginning" for -U0 matches.
I noticed this while trying out an example sequence from Clemens Buchacher:
$ echo a >victim
$ git add victim
$ echo b >>victim
$ git diff -U0 >patch
$ cat patch
diff --git i/victim w/victim
index 7898192..422c2b7 100644
--- i/victim
+++ w/victim
@@ -1,0 +2 @@ a
+b
$ git apply --cached --unidiff-zero <patch
$ git show :victim
b
a
The change inserts a new line before the second line, but we insist it to
be applied at the beginning. As the result, the code refuses to apply it
at the original offset, and we end up adding the line at the beginning.
Updates to the test script are by Clemens Buchacher.
Since 59d3f54 (name-rev: avoid "^0" when unneeded, 2007-02-20), name-rev
stopped showing an unnecessary "^0" to dereference a tag down to a commit.
The patch should have made a matching update to the documentation, but we
forgot.
The code failed to filter-out git-add properly on platforms were $X is
not empty (ATM there is only one such a platform).
Than it tried to create a hardlink to the file ($execdir/git-add) it just
removed (because git-add is first in the BUILT_INS), so ln failed (but
because stderr was redirected into /dev/null the error was never seen), and
the whole install ended up using "ln -s" instead.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fixup_pack_header_footer(): use nicely aligned buffer sizes
It should be more efficient to use nicely aligned buffer sizes, either
for filesystem operations or SHA1 checksums. Also, using a relatively
small nominal size might allow for the data to remain in L1 cache
between both SHA1_Update() calls.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
index-pack: use fixup_pack_header_footer()'s validation mode
When completing a thin pack, a new header has to be written to
the pack and a new SHA1 computed. Make sure that the SHA1 of what
is being read back matches the SHA1 of what was written for both:
the original pack and the appended objects.
To do so, a couple write_or_die() calls were converted to sha1write()
which has the advantage of doing some buffering as well as handling
SHA1 and CRC32 checksum already.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-objects: use fixup_pack_header_footer()'s validation mode
When limiting the pack size, a new header has to be written to the
pack and a new SHA1 computed. Make sure that the SHA1 of what is being
read back matches the SHA1 of what was written.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, this function has the potential to read corrupted pack data
from disk and give it a valid SHA1 checksum. Let's add the ability to
validate SHA1 checksum of existing data along the way, including before
and after any arbitrary point in the pack.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-objects: improve returned information from write_one()
This function returns 0 when the current object couldn't be written
due to the pack size limit, otherwise the current offset in the pack.
There is a problem with this approach however, since current object
could be a delta and its delta base might just have been written in
the same write_one() call, but those successfully written objects are
not accounted in the offset variable tracked by the caller. Currently
this is not an issue but a subsequent patch will need this.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
tutorial: gentler illustration of Alice/Bob workflow using gitk
pretty=format: respect date format options
make git-shell paranoid about closed stdin/stdout/stderr
Document gitk --argscmd flag.
Fix '--dirstat' with cross-directory renaming
for-each-ref: Allow a trailing slash in the patterns
git-p4: Fix checkout bug when using --import-local.
When this option is passed to git p4 clone, the checkout at the end would
previously fail. This patch fixes it by optionally creating the master branch
from refs/heads/p4/master, which is the correct one for this option.
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com> Acked-By: Simon Hausmann <simon@lst.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
the date option was ignored. This patch causes it to use whatever
format was specified by --date (or by --relative-date, etc), just
as the non-user formats would do.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
make git-shell paranoid about closed stdin/stdout/stderr
It is in general unsafe to start a program with one or more of file
descriptors 0/1/2 closed. Karl Chen for example noticed that stat_command
does this in order to rename a pipe file descriptor to 0:
dup2(from, 0);
close(from);
... but if stdin was closed (for example) from == 0, so that
dup2(0, 0);
close(0);
just ends up closing the pipe. Another extremely rare but nasty problem
would occur if an "important" file ends up in file descriptor 2, and is
corrupted by a call to die().
Fixing this in git was considered to be overkill, so this patch works
around it only for git-shell. The fix is simply to open all the "low"
descriptors to /dev/null in main.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Acked-by: Stephen R. van den Berg <srb@cuci.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The dirstat code depends on the fact that we always generate diffs with
the names sorted, since it then just does a single-pass walk-over of the
sorted list of names and how many changes there were. The sorting means
that all files are nicely grouped by directory.
That all works fine.
Except when we have rename detection, and suddenly the nicely sorted list
of pathnames isn't all that sorted at all. And now the single-pass dirstat
walk gets all confused, and you can get results like this:
Spot the difference. In case anybody wonders: it's because of a ton of
renames from {include/asm-blackfin => arch/blackfin/include/asm} that just
totally messed up the file ordering in between arch/arm and arch/powerpc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
for-each-ref: Allow a trailing slash in the patterns
More often than not, I end up using something like refs/remotes/ as the
pattern for for-each-ref, but that doesn't work, because it expects to see
the slash in the ref name right after the matched pattern. So teach it to
accept the slash as the final character in the pattern as well.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
is a c99 construct which some compilers do not support even though they
support other c99 constructs. This construct can be avoided by folding
these 'special' test cases into the sane_ctype array and making use of
the related infrastructure.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mv/merge-custom:
t7606: fix custom merge test
Fix "git-merge -s bogo" help text
Update .gitignore to ignore git-help
Builtin git-help.
builtin-help: always load_command_list() in cmd_help()
Add a second testcase for handling invalid strategies in git-merge
Add a new test for using a custom merge strategy
builtin-merge: allow using a custom strategy
builtin-help: make some internal functions available to other builtins
Some platforms contaminate the preprocessor token namespace with their own
definition of SS without being asked. Avoid getting hit by redefinition
warning messages by explicitly undef SS, AA and DD shorthand we use in this
table definition.
index-pack: be careful after fixing up the header/footer
The index-pack command, when processing a thin pack, fixed up the pack
after-the-fact. It forgets to fsync the result, because it only did that
in one path rather in all cases of fixup.
This moves the fsync_or_die() to the fix-up routine itself, rather than
doing it in one of the callers, so that all cases are covered.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it possible to abort the submission of a change to Perforce
Currently it is not possible to skip the submission of a change to Perforce
when running git-p4 submit. This patch compares the modification time before
and after the submit editor invokation and offers a prompt for skipping if
the submit template file was not saved.
Signed-off-by: Simon Hausmann <simon@lst.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
format-patch: use default diff format even with patch options
Previously, running "git format-patch -U5" would cause the
low-level diff machinery to change the diff output format
from "not specified" to "patch". This meant that
format-patch thought we explicitly specified a diff output
format, and would not use the default format. The resulting
message lacked both the diffstat and the summary, as well as
the separating "---".
Now format-patch explicitly checks for this condition and
uses the default. That means that "git format-patch -p" will
now have the "-p" ignored.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git index-pack" is an independent command and does not setup git
repository while still need pack.indexversion. It may miss the
info if it is in a subdirectory of the repository.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, when testing if the filesystem allows tabs in
filenames, bash issues an error something like:
./t4016-diff-quote.sh: pathname with HT: No such file or directory
which is caused by the failure of the (stdout) redirection,
since the file cannot be created. In order to suppress the
error message, you must redirect stderr to /dev/null, *before*
the stdout redirection on the command-line.
Also, remove a redundant filesystem check from the begining of
the t3902-quoted.sh test and standardise the "test skipped"
message to 'say' on exit.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: always provide a fallback when hardlinks fail
We make hardlinks from "git" to "git-<cmd>" built-ins and have been
careful to avoid cross-device links when linking "git-<cmd>" to
gitexecdir.
However, we were not prepared to deal with a build directory that is
incapable of making hard links within itself. This patch corrects it.
Instead of temporarily linking "git" to gitexecdir, directly link "git-
add", falling back to "cp". Try hardlinking that as "git-<cmd>", falling
back to symlinks or "cp" on error.
While at it, avoid 100+ error messages from hardlink failures when we are
going to fall back to symlinks or "cp" by redirecting the standard error
to /dev/null.
Signed-off-by: Andreas Färber <andreas.faerber@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit daa0cc9a92c9c2c714aa5f7da6d0ff65b93e0698.
It was a stupid idea to do this; when run as a log-in shell,
it is spawned with argv[0] set to "-git-shell", so the usual
name-based dispatch would not work to begin with.
This has been broken in v1.6.0 due to the reorganization of
the revision option parsing code. The "-i" is completely
ignored, but works fine in "git log --grep -i".
What happens is that the code for "-i" looks for
revs->grep_filter; if it is NULL, we do nothing, since there
are no grep filters. But that is obviously not correct,
since we want it to influence the later --grep option. Doing
it the other way around works, since "-i" just impacts the
existing grep_filter option.
Instead, we now always initialize the grep_filter member and
just fill in options and patterns as we get them. This means
that we can no longer check grep_filter for NULL, but
instead must check the pattern list to see if we have any
actual patterns.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
/etc/passwd shell field must be something execable, you can't enter
"/usr/bin/git shell" there. git-shell must be present as a separate
executable, or it is useless.
Signed-off-by: Tommi Virtanen <tv@eagain.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-submodule - Use "get_default_remote" from git-parse-remote
Resolve_relative_url was using its own code for this function, but
this is duplication with the best result that this continues to work.
Replace with the common function provided by git-parse-remote.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was not obvious from the text that pager.<cmd> is a boolean
setting.
While we're changing the description, make some other
improvements: lest we forget and fret, clarify that -p and
pager.<cmd> do not kick in when stdout is not a tty; point to
related core.pager and GIT_PAGER settings; use renamed --paginate
option.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix git-diff to make it produce useful 3-way diffs for merge conflicts in
repositories with autocrlf enabled. Otherwise it always reports that the
whole file was changed, because it uses the contents from the working tree
without necessary conversion.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Custom merge strategy does not even kick in when the merge is truly
trivial. The test depended on the behaviour in the git-merge rewritten in
C that broke the trivial merge completely.
Make the test to work on a non-trivial merge to make sure the strategy
kicks in.
* maint:
unpack_trees(): protect the handcrafted in-core index from read_cache()
git-p4: Fix one-liner in p4_write_pipe function.
Completion: add missing '=' for 'diff --diff-filter'
Fix 'git help help'
merge: fix numerus bugs around "trivial merge" area
The "trivial merge" codepath wants to optimize itself by making an
internal call to the read-tree machinery, but it does not read the index
before doing so, and the codepath is never exercised. Incidentally, this
failure to read the index upfront means that the safety to refuse doing
anything when the index is unmerged does not kick in, either.
These two problem are fixed by using read_cache_unmerged() that does read
the index before checking if it is unmerged at the beginning of
cmd_merge().
The primary logic of the merge, however, assumes that the process never
reads the index in-core, and the call to write_cache_as_tree() it makes
from write_tree_trivial() will always read from the on-disk index that is
prepared the strategy back-ends. This assumption is now broken by the
above fix. To fix this issue, we now call discard_cache() before calling
write_tree_trivial() when it wants to write the on-disk index as a tree.
When multiple strategies are tried, their results are evaluated by reading
the resulting index and inspecting it. The codepath needs to make a call
to read_cache() for each successful strategy, and for that to work, they
need to discard_cache() the one read by the previous round.
Also the "trivial merge" forgot that the current commit is one of the
parents of the resulting commit.
unpack_trees(): protect the handcrafted in-core index from read_cache()
unpack_trees() rebuilds the in-core index from scratch by allocating a new
structure and finishing it off by copying the built one to the final
index.
The resulting in-core index is Ok for most use, but read_cache() does not
recognize it as such. The function is meant to be no-op if you already
have loaded the index, until you call discard_cache().
This change the way read_cache() detects an already initialized in-core
index, by introducing an extra bit, and marks the handcrafted in-core
index as initialized, to avoid this problem.
A better fix in the longer term would be to change the read_cache() API so
that it will always discard and re-read from the on-disk index to avoid
confusion. But there are higher level API that have relied on the current
semantics, and they and their users all need to get converted, which is
outside the scope of 'maint' track.
An example of such a higher level API is write_cache_as_tree(), which is
used by git-write-tree as well as later Porcelains like git-merge, revert
and cherry-pick. In the longer term, we should remove read_cache() from
there and add one to cmd_write_tree(); other callers expect that the
in-core index they prepared is what gets written as a tree so no other
change is necessary for this particular codepath.
The original version of this patch marked the index by pointing an
otherwise wasted malloc'ed memory with o->result.alloc, but this version
uses Linus's idea to use a new "initialized" bit, which is conceptually
much cleaner.
Revert "Convert output messages in merge-recursive to past tense."
During a conflicting merge, you would typically see:
Auto-merged foo.txt
CONFLICT (content): Merge conflict in foo.txt
Recorded preimage for 'foo.txt'
Automatic merge failed; fix conflicts and then commit the result.
and left wondering what happened to "foo.txt". Did it succeed, and then
conflicted, and then what?
This is because historically there was a progress bar displayed before the
auto-merge is mentioned, and it was expected to take long time, before we
can say "Auto-merged foo.txt". It turns out it was not the case, and the
original wording "Auto-merging foo.txt" we used to have before 89f40be
(Convert output messages in merge-recursive to past tense., 2007-01-14) is
better.
Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
templates/Makefile: install is unnecessary, just use mkdir -p
The native install on some platforms (namely IRIX 6.5) treats non-absolute
paths as being relative to the root directory rather than relative to
the current directory. Work around this by avoiding install in this case
since it is unnecessary, and instead depend on the local umask setting
and use mkdir.
Tested-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote.c: add a function for deleting a refspec array and use it (twice)
A number of call sites allocate memory for a refspec array, populate
its members with heap memory, and then free only the refspec pointer
while leaking the memory allocated for the member elements. Provide
a function for freeing the elements of a refspec array and the array
itself.
Caution to callers: code paths must be checked to ensure that the
refspec members "src" and "dst" can be passed to free.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
filter-branch: Grok special characters in tag names
The tag rewriting code used a 'sed' expression to substitute the new tag
name into the corresponding field of the annotated tag object. But this is
problematic if the tag name contains special characters. In particular,
if the tag name contained a slash, then the 'sed' expression had a syntax
error. We now protect against this by using 'printf' to assemble the
tag header.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
provide more errors for the "merge into empty head" case
A squash merge into an unborn branch could be implemented by building the
index from the merged-from branch, and doing a single commit, but this is
not supported yet.
A non-fast-forward merge into an unborn branch does not make any sense,
because you cannot make a merge commit if you don't have a commit to use
as the parent.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make reflog query '@{1219188291}' act as '@{2008.8.19.16:24:51.-0700}'
As we support seconds-since-epoch in $GIT_COMMITTER_TIME we should
also support it in a reflog @{...} style notation. We can easily
tell this part from @{nth} style notation by looking to see if the
value is unreasonably large for an @{nth} style notation.
The value 100000000 was chosen as it is already used by date.c to
disambiguate yyyymmdd format from a seconds-since-epoch time value.
A reflog with 100,000,000 record entries is also simply not valid.
Such a reflog would require at least 7.7 GB to store just the old
and new SHA-1 values. So our randomly chosen upper limit for @{nth}
notation is "big enough".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configure script allows you to specify flags to pass to the linker
step in the LDFLAGS environment variable but this was being ignored in
the Makefile. Now a make variable gets set to the value passed down
from the configure script.
Signed-off-by: Neil Roberts <bpeeluk@yahoo.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-submodule.sh - Remove trailing / from URL if found
git clone does not complain if a trailing '/' is included in the origin
URL, but doing so causes resolution of a submodule's URL relative to the
superproject to fail. Trailing /'s are likely when cloning locally using
tab-completion, so the slash may appear in either superproject or
submodule URL. So, ignore the trailing slash if it already exists in
the superproject's URL, and don't record one for the submodule (which
could itself have submodules...).
The problem I'm trying to fix is that a number of folks have
superprojects checked out where the recorded origin URL has a trailing
/, and a submodule has its origin in a directory sitting right next to
the superproject on the server. Thus, we have:
However, in the checked out superproject's .git/config
[remote "origin"]
url = server:/public/super/
and for similar reasons, the submodule has its URL recorded in .gitmodules as
[submodule "sub"]
path = submodule1
url = ../sub1/
resolve_relative_url gets the submodule's recorded url as $1, which
the caller retrieved from .gitmodules, and retrieves the superprojects
origin from .git/config. So in this case resolve_relative_url has
that:
url = ../sub1/
remoteurl = server:/public/super/
So, without any patch, resolve_relative_url computes the submodule's URL as:
server:/public/super/sub1/
rather than
server:/public/sub1
In summary, it is essential that resolve_relative_url strip the
trailing / from the superproject's url before starting, and
beneficial if it assures that the result does not contain
a trailing / as the submodule may itself also be a superproject.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git help foo invokes man git-foo if foo is a git command, otherwise it
invokes man gitfoo. 'help' is not a git command, but the manual page is
called git-help, so add this special exception.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Acked-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
compat/snprintf.c: handle snprintf's that always return the # chars transmitted
git-svn: fix dcommit to urls with embedded usernames
revision.h: make show_early_output an extern which is defined in revision.c
compat/snprintf.c: handle snprintf's that always return the # chars transmitted
Some platforms provide a horribly broken snprintf. More broken than the
platforms that return -1 when there is too little space in the target buffer
for the formatted string. Some platforms provide an snprintf which _always_
returns the number of characters transmitted to the buffer, regardless of
whether there was enough space or not.
IRIX 6.5 is such a platform. IRIX does have a working snprintf(), but it
is only provided when _NO_XOPEN5 evaluates to zero, and this only happens
if _XOPEN_SOURCE is defined, but definition of _XOPEN_SOURCE prevents
inclusion of many other common functions and defines. So it must be avoided.
Work around these horribly broken snprintf implementations by detecting an
snprintf call which results in the number of transmitted characters exactly
equal to the length of our buffer and retrying with a larger buffer just to
be safe.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Acked-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: fix dcommit to urls with embedded usernames
Don't rely on the extracted URL from working_head_info since that has the
username removed. Instead use the $gs->full_url method (as before with ba24e74 (git-svn: add ability to specify --commit-url for dcommit,
2008-08-07)) to give us the URL to commit to if --commit-url is not
specified.
Aditionally, since we clean usernames from URLs, checking the URL after
rebase can fail because it doesn't match the URL we used to commit; so
unconditionally provide a username-free URL for checking the result of the
refetch.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>