cherry-pick will segfault when transplanting a root commit if the --ff
option is used. This happens because the "parent" pointer is set to NULL
when the commit being cherry-picked has no parents. Later, when "parent"
is dereferenced, the cherry-pick segfaults.
Fix this by checking whether "parent" is NULL before dereferencing it and
add a test for this case of cherry-picking a root commit with --ff.
Reported-by: Zbyszek Szmek <zbyszek@in.waw.pl>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cherry-pick fails after picking a large series of commits, it can
be hard to pick out the error message and advice. Prefix the advice
with “hint: ” to help.
Before:
error: could not apply 7ab78c9... foo
After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with:
git commit -c 7ab78c9a7898b87127365478431289cb98f8d98f
After:
error: could not apply 7ab78c9... foo
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit -c 7ab78c9'
Noticed-by: Thomas Rast <trast@student.ethz.ch>
Encouraged-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cherry-pick fails after picking a large series of commits, it can
be hard to pick out the error message and advice. Clarify the error
and prefix it with “error: ” to help.
Before:
Automatic cherry-pick failed. [...advice...]
After:
error: could not apply 7ab78c9... Do something neat.
[...advice...]
Noticed-by: Thomas Rast <trast@student.ethz.ch>
Encouraged-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like error(), warn(), and die(), advise() prints a short message
with a formulaic prefix to stderr.
It is local to revert.c for now because I am not sure this is
the right API (we may want to take an array of advice lines or a
boolean argument for easy suppression of unwanted advice).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cherry-pick was written (v0.99.6~63, 2005-08-27), “git commit”
was quiet, and the output from cherry-pick provided useful information
about the progress of a rebase.
Now next to the output from “git commit”, the cherry-pick notification
is so much noise (except for the name of the picked commit).
$ git cherry-pick ..topic
Finished cherry-pick of 499088b.
[detached HEAD 17e1ff2] Move glob module to libdpkg
Author: Guillem Jover <guillem@debian.org>
8 files changed, 12 insertions(+), 9 deletions(-)
rename {src => lib/dpkg}/glob.c (98%)
rename {src => lib/dpkg}/glob.h (93%)
Finished cherry-pick of ae947e1.
[detached HEAD 058caa3] libdpkg: Add missing symbols to Versions script
Author: Guillem Jover <guillem@debian.org>
1 files changed, 2 insertions(+), 0 deletions(-)
$
The noise is especially troublesome when sifting through the output of
a rebase or multiple cherry-pick that eventually failed.
With the commit subject, it is already not hard to figure out where
the commit came from. So drop the “Finished” message.
Cc: Christian Couder <chriscool@tuxfamily.org>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach "git merge-recursive" a --renormalize option to enable the
merge.renormalize configuration. The --no-renormalize option can
be used to override it in the negative.
So in the future, you might be able to, e.g.:
git checkout -m -Xrenormalize otherbranch
or
git revert -Xrenormalize otherpatch
or
git pull --rebase -Xrenormalize
The bad part: merge.renormalize is still not honored for most
commands. And it reveals lots of places that -X has not been plumbed
in (so we get "git merge -Xrenormalize" but not much else).
NEEDSWORK: tests
Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Generic-looking pointer variable "p" was used only to point at subject
string and had a rather lifespan.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A test case is added but the problem can only be seen when running
the test case with --valgrind.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of saying "Finished one cherry-pick." or "Finished one revert.",
we now say "Finished cherry-pick of commit <abbreviated sha1>." or
"Finished revert of commit <abbreviated sha1>." which is more informative,
especially when cherry-picking or reverting many commits.
In case of failure the message is now "Automatic cherry-pick of commit
<abbreviated sha1> failed." instead of "Automatic cherry-pick failed."
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git cherry-pick foo" has always reported success with
"Finished one cherry-pick" but "cherry-pick --strategy"
does not print anything. So move the code to write that
message from do_recursive_merge() to do_cherry_pick()
so other strategies can share it.
This patch also refactors the code that prints a message
like "Automatic cherry-pick failed. <help message>". This
code was duplicated in both do_recursive_merge() and
do_pick_commit().
To do that, now do_recursive_merge() returns an int to signal
success or failure. And in case of failure we just return 1
from do_pick_commit() instead of doing "exit(1)" from either
do_recursive_merge() or do_pick_commit().
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set options in struct rev_info directly so we can reuse the
arguments collected from parse_options without modification.
This is just a cleanup; no noticeable change is intended.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This can be useful to do something like:
git rev-list --reverse master -- README | git cherry-pick -n --stdin
without using xargs.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes it possible to pass many commits or ranges of
commits to "git cherry-pick" and to "git revert" to process
many commits instead of just one.
In fact commits are now enumerated with an equivalent of
git rev-list --no-walk "$@"
so all the following are now possible:
git cherry-pick master~2..master
git cherry-pick ^master~2 master
git cherry-pick master^ master
The following should be possible but does not work:
git cherry-pick -2 master
because "git rev-list --no-walk -2 master" only outputs
one commit as "--no-walk" seems to take over "-2".
And there is currently no way to continue cherry-picking or
reverting if there is a problem with one commit. It's also
not possible to abort the whole process. Some future work
should provide the --continue and --abort options to do
just that.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed because the following commits will make it
possible to cherry-pick many commits instead of just one.
So it will be possible to pass for example ranges of commits
to "git cherry-pick" and this means that it will not be
possible to use the arguments passed to "git cherry-pick" in
the help message.
The help message will have to use the sha1 of the currently
processed commit.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed because we are going to make it possible
to cherry-pick many commits instead of just one in the following
commits. And we will be able to do that by just calling
do_pick_commit() once for each commit to cherry-pick.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed by the following commits, because we are going
to cherry pick many commits instead of just one.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was some dead code and option -x appeared in the short
help message of git revert (when running "git revert -h")
which was wrong.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cherry-picking, usually the new and old commit encodings are both
UTF-8. Most old iconv implementations do not support this trivial
conversion, so on old platforms, out->message remains NULL, and later
attempts to read it segfault.
Fix this by noticing the input and output encodings match and skipping
the iconv step, like the other reencode_string() call sites already do.
Also stop segfaulting on other iconv failures: if iconv fails for some
other reason, the best we can do is to pass the old message through.
This fixes a regression introduced in v1.7.1-rc0~15^2~2 (revert:
clarify label on conflict hunks, 2010-03-20).
Reported-by: Andreas Krey <a.krey@gmx.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch makes it possible to use a different merge strategy when
cherry-picking. This is usefull mainly for debugging purposes as it
allows to see if some failures are caused by the merge strategy used or
not.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code that is used to do a recursive merge is extracted from
the revert_or_cherry_pick() function and put into a new
do_recursive_merge() function.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code in this commit was written by Stephan Beyer for the sequencer
GSoC project:
git://repo.or.cz/git/sbeyer.git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When writing conflict hunks in ‘diff3 -m’ format, also add a label to
the common ancestor. Especially in a cherry-pick, it is not immediately
obvious without such a label what the common ancestor represents.
git rerere does not have trouble parsing the new output and its preimage
ids are unchanged since it includes its own code for recreating conflict
hunks. No other code in git parses conflict hunks.
Requested-by: Stefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When reverting a commit, the commit being merged is not the commit
to revert itself but its parent. Add “parent of” to the conflict
hunk label to make this more clear.
The conflict hunk labels are all pieces of a single string written in
the new get_message() function. Avoid some complication by using
mempcpy to advance a pointer as the result is written.
Also free the corresponding temporary buffer (it was leaked before).
This is not important because it is a small one-time allocation. It
would become a memory leak if unnoticed when libifying revert.
This patch uses calls to strlen() instead of integer constants in some
places. GCC will compute the length at compile time; I am not sure
about other compilers, but this is not performance-critical anyway.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This shrinks the top-level directory a bit, and makes it much more
pleasant to use auto-completion on the thing. Instead of
[torvalds@nehalem git]$ em buil<tab>
Display all 180 possibilities? (y or n)
[torvalds@nehalem git]$ em builtin-sh
builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c
builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o
[torvalds@nehalem git]$ em builtin-shor<tab>
builtin-shortlog.c builtin-shortlog.o
[torvalds@nehalem git]$ em builtin-shortlog.c
you get
[torvalds@nehalem git]$ em buil<tab> [type]
builtin/ builtin.h
[torvalds@nehalem git]$ em builtin [auto-completes to]
[torvalds@nehalem git]$ em builtin/sh<tab> [type]
shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o
[torvalds@nehalem git]$ em builtin/sho [auto-completes to]
[torvalds@nehalem git]$ em builtin/shor<tab> [type]
shortlog.c shortlog.o
[torvalds@nehalem git]$ em builtin/shortlog.c
which doesn't seem all that different, but not having that annoying
break in "Display all 180 possibilities?" is quite a relief.
NOTE! If you do this in a clean tree (no object files etc), or using an
editor that has auto-completion rules that ignores '*.o' files, you
won't see that annoying 'Display all 180 possibilities?' message - it
will just show the choices instead. I think bash has some cut-off
around 100 choices or something.
So the reason I see this is that I'm using an odd editory, and thus
don't have the rules to cut down on auto-completion. But you can
simulate that by using 'ls' instead, or something similar.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's hard to see the "how to commit" part of this message,
which users may want to cut and paste. On top of that,
having it in paragraph form means that a really long commit
name may cause ugly wrapping. Let's make it prettier, like:
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with:
git commit -c HEAD~23
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we have a conflict, we advise the user to do:
git commit -c $sha1
This works fine, but is unnecessarily confusing and annoying
for the user to type, when:
git commit -c $the_thing_you_called_cherry_pick_with
works just as well.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This gets rid of the fixed-size buffer and an unchecked
sprintf. That sprintf is actually OK as the only
variable-sized thing put in it is an abbreviated sha1, which
is bounded at 40 characters. However, the next patch will
change that to something unbounded.
Note that this function now returns an allocated buffer
instead of a static one; however, it doesn't matter as the
only caller exits immediately.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These lines are really just lookup_commit_reference
re-implemented.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current message overflows on an 80-character terminal.
While we're at it, fix the spelling of 'committing'.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lots of die() calls did not actually report the kind of error, which
can leave the user confused as to the real problem. Use die_errno()
where we check a system/library call that sets errno on failure, or
one of the following that wrap such calls:
Function Passes on error from
-------- --------------------
odb_pack_keep open
read_ancestry fopen
read_in_full xread
strbuf_read xread
strbuf_read_file open or strbuf_read_file
strbuf_readlink readlink
write_in_full xwrite
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To give OPT_FILENAME the prefix, we pass the prefix to parse_options()
which passes the prefix to parse_options_start() which sets the prefix
member of parse_opts_ctx accordingly. If there isn't a prefix in the
calling context, passing NULL will suffice.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some ancient platforms (Solaris 7, IRIX 6.5) do not understand 'utf-8', but
all tested implementations understand 'UTF-8'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a cherry-pick of an empty commit is done, release the lock
held on the index.
The fix is the same as was applied to similar code in 4271666046.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
index_is_dirty() in builtin-revert.c checks if the index is dirty.
This patch generalizes this function to check if the index differs
from a revision, i.e. the former index_is_dirty() behavior can now be
achieved by index_differs_from("HEAD", 0).
The second argument "diff_flags" allows to set further diff option
flags like DIFF_OPT_IGNORE_SUBMODULES. See DIFF_OPT_* macros in diff.h
for a list.
index_differs_from() seems to be useful for more than builtin-revert.c,
so it is moved into diff-lib.c and also used in builtin-commit.c.
Yet to mention:
- "rev.abbrev = 0;" can be safely removed.
This has no impact on performance or functioning of neither
setup_revisions() nor run_diff_index().
- rev.pending.objects is free()d because this fixes a leak.
(Also see 295dd2ad "Fix memory leak in traverse_commit_list")
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As described in Documentation/howto/revert-a-faulty-merge.txt, re-merging
from a previously reverted a merge of a side branch may need a revert of
the revert beforehand. Record against which parent the revert was made in
the commit, so that later the user can figure out what went on.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes the "die_on_error" boolean parameter to a mere "flags", and
changes the existing callers of hold_lock_file_for_update/append()
functions to pass LOCK_DIE_ON_ERROR.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactored merge-recursive interface may still not be ideal but it already
allows us to make a direct call to merge_tree().
One regression is that the status message is lost as there is no way to
flush them from outside the refactored library code yet.
[jc: initial version by Miklos, with moderate amount of fixup by me]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cherry-picking can be helped by reusing previous confliction
resolution by invoking rerere automatically.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form. So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.
This patch makes git commands show the dash-less version.
For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A root commit couldn't be cherry-picked. But its semantics can be
defined as simply merging two trees by overlaying disjoint parts
and merging overlapping files without any common ancestor. You
should be able to rebase originally independent branches on top of
another branch by using this.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git_config() only had a function parameter, but no callback data
parameter. This assumes that all callback functions only modify
global variables.
With this patch, every callback gets a void * parameter, and it is hoped
that this will help the libification effort.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brandon Casey