* 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>
* 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
* am/maint-push-doc:
Documentation: avoid using undefined parameters
Documentation: mention branches rather than heads
Documentation: remove a redundant elaboration
Documentation: git push repository can also be a remote
The documentation for git-describe says the default abbreviation is 8
hexadecimal digits while cache.c clearly shows DEFAULT_ABBREV set to 7.
This patch corrects the documentation.
Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All the other config variables use CamelCase. This config variable should
not be an exception.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In diffcore_rename, we assume that the blob contents in the filespec
aren't required anymore after estimate_similarity has been called and thus
we free it. But estimate_similarity might return early when the file sizes
differ too much. In that case, cnt_data is never set and the next call to
estimate_similarity will populate the filespec again, eventually rereading
the same blob over and over again.
To fix that, we first get the blob sizes and only when the blob contents
are actually required, and when cnt_data will be set, the full filespec is
populated, once.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-shell's man page explicitly lists all allowed commands, but 'cvs
server' was missing. Add it.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The <ref> parameter has not been introduced, so rewrite to
avoid it.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "matching refs" semantics works only on matching branches these days.
Instead of using "heads" which traditionally has been used more or less
interchangeably with "refs", say "branch" explicitly here.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comment in parentheses is wrong, as one has to leave out both the
colon and <dst>. This situation is covered by the section a few lines
down:
A parameter <ref> without a colon pushes the <ref> from the source
repository to the destination repository under the same name.
So, just remove the parentheses.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is copied from pull-fetch-param.txt and helps the reader
to not get stuck in the URL section.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.0:
builtin-fsck: fix off by one head count
Documentation: let asciidoc align related options
githooks.txt: add missing word
builtin-commit.c: do not remove COMMIT_EDITMSG
According to the man page, if "git fsck" is passed one or more heads, it
should verify connectivity and validity of only objects reachable from the
heads it is passed.
However, since 5ac0a20 (Make builtin-fsck.c use parse_options.,
2007-10-15) the command behaved as if no heads were passed, when given
only one argument.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano