summaryrefslogtreecommitdiff
path: root/t/t3507-cherry-pick-conflict.sh
diff options
context:
space:
mode:
authorPhillip Wood <phillip.wood@dunelm.org.uk>2019-12-06 16:06:12 (GMT)
committerJunio C Hamano <gitster@pobox.com>2019-12-06 17:32:02 (GMT)
commit430b75f7209c554d88e3554eb54cebf4ba1e4608 (patch)
tree6745a135ed8abea555e14fe2d28a4805793b8531 /t/t3507-cherry-pick-conflict.sh
parent901ba7b1efe8ba9464aac528ecd46e8dd4f01003 (diff)
downloadgit-430b75f7209c554d88e3554eb54cebf4ba1e4608.zip
git-430b75f7209c554d88e3554eb54cebf4ba1e4608.tar.gz
git-430b75f7209c554d88e3554eb54cebf4ba1e4608.tar.bz2
commit: give correct advice for empty commit during a rebase
In dcb500dc16c (cherry-pick/revert: advise using --skip, 2019-07-02), `git commit` learned to suggest to run `git cherry-pick --skip` when trying to cherry-pick an empty patch. However, it was overlooked that there are more conditions than just a `git cherry-pick` when this advice is printed (which originally suggested the neutral `git reset`): the same can happen during a rebase. Let's suggest the correct command, even during a rebase. While at it, we adjust more places in `builtin/commit.c` that incorrectly assumed that the presence of a `CHERRY_PICK_HEAD` meant that surely this must be a `cherry-pick` in progress. Note: we take pains to handle the situation when a user runs a `git cherry-pick` _during_ a rebase. This is quite valid (e.g. in an `exec` line in an interactive rebase). On the other hand, it is not possible to run a rebase during a cherry-pick, meaning: if both `rebase-merge/` and `sequencer/` exist or CHERRY_PICK_HEAD and REBASE_HEAD point to the same commit , we still want to advise to use `git cherry-pick --skip`. Original-patch-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t3507-cherry-pick-conflict.sh')
0 files changed, 0 insertions, 0 deletions