In https://github.com/git-for-windows/git/issues/952, a complicated
scenario was described that leads to a segmentation fault in
cherry-pick.
It boils down to a certain code path involving a renamed file that is
dirty, for which `refresh_cache_entry()` returns `NULL`, and that
`NULL` not being handled properly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git cherry-pick" without further options would segfault.
Could use a follow-up to handle '-' after argv[1] better.
* hu/cherry-pick-previous-branch:
cherry-pick: handle "-" after parsing options
Currently, we only try converting argv[1] from "-" into "@{-1}". This
means we do not notice "-" when used together with an option. Worse,
when "git cherry-pick" is run with no options, we segfault. Fix this
by doing the substitution after we have checked that there is
something in argv to cherry-pick and know any remaining options are
meant for the revision-listing machinery.
This still does not handle "-" after the first non-cherry-pick option.
For example,
git cherry-pick foo~2 - bar~5
and
git cherry-pick --no-merges -
will still dump usage.
Reported-by: Stefan Beller <stefanbeller@googlemail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Just like "git checkout -" knows to check out and "git merge -"
knows to merge the branch you were previously on, "git cherry-pick"
now understands "git cherry-pick -" to pick from the previous
branch.
* hu/cherry-pick-previous-branch:
cherry-pick: allow "-" as abbreviation of '@{-1}'
"-" abbreviation is handy for "cherry-pick" like "checkout" and "merge".
It's also good for uniformity that a "-" stands as
the name of the previous branch where a branch name is
accepted and it could not mean any other things like stdin.
Signed-off-by: Hiroshige Umino <hiroshige88@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cherry-picking into an unborn branch should work, so make it work,
with or without --ff.
Cherry-picking anything other than a commit that only adds files, will
naturally result in conflicts. Similarly, revert also works, but will
result in conflicts unless the specified revision only deletes files.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the i18n-specific test functions in test scripts for parseopt tests.
This issue was was introduced in v1.7.10.1-488-g54e6d:
54e6d i18n: parseopt: lookup help and argument translations when showing usage
and been broken under GETTEXT_POISON=YesPlease since.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Translate the "Your local changes [...]" message without using the
`me' variable, instead split up the two messages so translators can
translate the whole messages as-is.
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A stat-dirty index is not a detail that ought to concern the operator
of porcelain such as "git cherry-pick".
Without this change, a cherry-pick after copying a worktree with rsync
errors out with a misleading message.
$ git cherry-pick build/top
error: Your local changes to 'file.h' would be overwritten by merge. Aborting.
Please, commit your changes or stash them before you can merge.
Noticed-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/cherry-pick-stdin:
revert: do not rebuild argv on heap
revert: accept arbitrary rev-list options
t3508 (cherry-pick): futureproof against unmerged files
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>
The environment variable GIT_REFLOG_ACTION was used by git-commit.sh,
but when it was converted to a builtin
(f5bbc3225c, Port git commit to C,
Nov 8 2007) this was lost.
Let's use it again as it is more user friendly when reverting or
cherry-picking to see "revert" or "cherry-pick" in the reflog rather
than to just see "commit".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
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>
The basic idea of t3501 is to check whether revert
and cherry-pick works on renamed files.
But as there is no pure cherry-pick/revert test, it is
good to also check if commits are actually done in that
scenario.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous code mistakenly used wt_status_prepare to check whether the
index had anything commitable in it; however, that function is just an
init function, and will never report a dirty index.
The correct way with wt_status_* would be to call wt_status_print with the
output pointing to /dev/null or similar. However, that does extra work by
both examining the working tree and spewing status information to nowhere.
Instead, let's just implement the useful subset of wt_status_print as an
"is_index_dirty" function.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They are already set and exoprted by sourcing ./test-lib.sh
in all test scripts.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes revert and cherry-pick to use merge-recursive, to
allow them to notice renames. A pair of test scripts
demonstrate that an old change before a rename happened can be
applied (reverted) after a rename with cherry-pick (with revert).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes Schindelin
Junio C Hamano
Jeff King
Hiroshige Umino
Martin von Zweigbergk
Jiang Xin
Ævar Arnfjörð Bjarmason
Jonathan Nieder
Christian Couder
Matthieu Moy
Stephan Beyer
Kristian Høgsberg
Junio C Hamano