An earlier commit a9cb3c6e changed git-commit to use the
contents of MERGE_MSG even when we do not have MERGE_HEAD (the
rationale is in its log message).
However, the change tricks the following sequence to include a
merge message in a completely unrelated commit:
$ git pull somewhere
: oops, the conflicts are too much. forget it.
$ git reset --hard
: work work work
$ git commit
To fix this confusion, this patch makes "git reset" to remove
the leftover MERGE_MSG that was prepared when the user abandoned
the merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Luben Tuikov <ltuikov@yahoo.com
The structure that ends with a flexible array member (or 0 length array with older GCC) "char name[FLEX_ARRAY]" is allocated on the stack and we use it after clearing its entire size with memset. That does not guarantee that "name" is properly NUL terminated as we intended on platforms with more forgiving structure alignment requirements. Reported breakage on m68k by Roman Zippel. Signed-off-by: Junio C Hamano <junkio@cox.net>
Especially refs/tags/ hierarchy should match what git-fetch checks. Signed-off-by: Junio C Hamano <junkio@cox.net>
A move of a directory should find the entries in the index by searching for the name _including_ the slash. Otherwise, the directory can be shadowed by a file when it matches the prefix and is lexicographically smaller, e.g. "ab.c" shadows "ab/". Noticed by Sergey Vlasov. [jc: added Sergey's original reproduction recipe as a test case at the end of t7001.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
SVN is not entirely consistent in returning log information and sometimes returns file information when adding subdirectories, and sometimes it does not (only returning information about the directory that was added). This caused git-svn to occasionally add a file to the list of files to be fetched twice. Now we change the data structure to be hash to avoid repeated fetches. As of now (in master), this only affects repositories fetched without deltas enabled (file://, and when manually overriden with GIT_SVN_DELTA_FETCH=0); so this bug mainly affects users of 1.4.4.1 and maint. Thanks to Florian Weimer for reporting this bug. [jc: backported for maint] Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Introducing yourself to git early would be a good idea; otherwise the user may not find the mistake until much later when "git log" is learned. Teaching "commit -a" without saying that it is a shortcut for listing the paths to commit leaves the user puzzled. Teach the form with explicit paths first. Signed-off-by: Junio C Hamano <junkio@cox.net>
We lacked "--" termination in the underlying init_revisions() call which made it impossible to specify a revision that happens to have the same name as an existing file. Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to get the case that more than two paths came from the same commit wrong when computing the output width and deciding to turn on --show-name option automatically. When we find that lines that came from a path that is different from what we started digging from, we should always turn --show-name on, and we should count the name length for all files involved. Signed-off-by: Junio C Hamano <junkio@cox.net>
In xemit.c:xdl_emit_diff() a buffer for showing the function name as commentary is allocated; this buffer was 40 characters. This is a bit small; particularly for C++ function names where there is often an identical prefix (like void LongNamespace::LongClassName) on multiple functions, which makes the context the same everywhere. In other words the context is useless. This patch increases that buffer to 80 characters - which may still not be enough, but is better Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>