After the git-core package was renamed to git, git help -w was still looking
for files in /usr/share/doc/git-core-$VERSION instead of
/usr/share/doc/git-$VERSION.
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.0:
builtin-mv.c: check for unversionned files before looking at the destination.
Add a testcase for "git mv -f" on untracked files.
Missing && in t/t7001.sh.
The previous code was failing in the case where one moves an
unversionned file to an existing destination, with mv -f: the
"existing destination" was checked first, and the error was cancelled
by the force flag.
We now check the unrecoverable error first, which fixes the bug.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, the exit status is only the one of the last line.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.0:
User-manual: "git stash <comment>" form is long gone
add test-dump-cache-tree in Makefile
fix typo in Documentation
apply: fix access to an uninitialized mode variable, found by valgrind
These days you must explicitly say "git stash save <comment>".
Signed-off-by: William Pursell <bill.pursell@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5c5ba73 (Makefile: Use generic rule to build test programs,
2007-05-31) tried to use generic rule to build test programs, but it
misses the file 'dump-cache-tree.c', since its name is not prefixed by
'test-'. This commit solves this little problem by renaming this file
instead of carrying out an explicit rule in Makefile.
Signed-off-by: Guanqun Lu <guanqun.lu@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'tpatch' was initialized successfully, st_mode was already taken
from the previous diff. We should not try to override it with data
from an lstat() that was never called.
This is a companion patch to 7a07841(git-apply: handle a patch that
touches the same path more than once better).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The parameter n of unpack_callback() can have a value of up to
MAX_UNPACK_TREES. The check at the top of unpack_trees() (its only
(indirect) caller) makes sure it cannot exceed this limit.
unpack_callback() passes it and the array src to unpack_nondirectories(),
which has this loop:
for (i = 0; i < n; i++) {
/* ... */
src[i + o->merge] = o->df_conflict_entry;
o->merge can be 0 or 1, so unpack_nondirectories() potentially accesses
the array src at index MAX_UNPACK_TREES. This patch makes it big enough.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The size of the content we are adding may be larger than
2.1G (i.e., "git add gigantic-file"). Most of the code-path
to do so uses size_t or unsigned long to record the size,
but write_loose_object uses a signed int.
On platforms where "int" is 32-bits (which includes x86_64
Linux platforms), we end up passing malloc a negative size.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
v1.6.1 introduced ".have" extension to the protocol to allow the receiving
side to advertise objects that are reachable from refs in the repositories
it borrows from. This was meant to be used by the sending side to avoid
sending such objects; they are already available through the alternates
mechanism.
The client side implementation in v1.6.1, which was introduced with
40c155f (push: prepare sender to receive extended ref information from the
receiver, 2008-09-09) aka v1.6.1-rc1~203^2~1, were faulty in that it did
not consider the possiblity that the repository receiver borrows from
might have objects it does not know about.
This fixes it by refraining from passing missing commits to underlying
pack-objects. Revision machinery may need to be tightened further to
treat missing uninteresting objects as non-error events, but this is an
obvious and safe fix for a maintenance release that is almost good enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When normalizing an absolute path, we might have to add a slash _and_ a
NUL to the buffer, so the buffer was one too small.
Let's just future proof the code and alloc PATH_MAX + 1 bytes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When get_sha1_basic() is passed a buffer of len 0, it should not
check if buf[len-1] is a curly bracket.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is an evil merge, as a test added since 1.6.0 expects an incorrect
behaviour the merged commit fixes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A patch that changes the filetype (e.g. regular file to symlink) of a path
must be split into a deletion event followed by a creation event, which
means that we need to have two independent metainfo lines for each.
However, the code reused the single set of metainfo lines.
As the blob object names recorded on the index lines are usually not used
nor validated on the receiving end, this is not an issue with normal use
of the resulting patch. However, when accepting a binary patch to delete
a blob, git-apply verified that the postimage blob object name on the
index line is 0{40}, hence a patch that deletes a regular file blob that
records binary contents to create a blob with different filetype (e.g. a
symbolic link) failed to apply. "git am -3" also uses the blob object
names recorded on the index line, so it would also misbehave when
synthesizing a preimage tree.
This moves the code to generate metainfo lines around, so that two
independent sets of metainfo lines are used for the split halves.
Additional tests by Jeff King.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This tries to make the description of ref matching in git push easier
to read. Beauty is in the eye of the beholder, though.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Include examples of using HEAD. The order of examples
introduces new concepts one by one. This pushes the
example of deleting a ref to the end of the list.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The refspec format description was a mix of regexp and BNF, making it
very difficult to read. The format was also wrong: it did not show
that each part of a refspec is optional in different situations.
Rather than having a confusing grammar, just present the format in
informal prose.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/maint-no-index-fixes:
diff --no-index -q: fix endless loop
diff --no-index: test for pager after option parsing
diff: accept -- when using --no-index
