If git rebase --merge encountered a conflict, --skip would not work if the
next commit also conflicted. The msgnum file would never be updated with
the new patch number, so no patch would actually be skipped, resulting in an
inescapable loop.
Update the msgnum file's value as the first thing in call_merge. This also
avoids an "Already applied" message when skipping a commit. There is no
visible change for the other contexts in which call_merge is invoked, as the
msgnum file's value remains unchanged in those situations.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase calls out to merge strategies, but did not support merge
strategy options so far. Add this, in the same style used in
git-merge.
Sadly we have to do the full quoting/eval dance here, since
merge-recursive supports the --subtree=<path> option which potentially
contains whitespace.
This patch does not cover git rebase -i, which does not call any merge
strategy directly except in --preserve-merges, and even then only for
merges.
[jc: with a trivial fix-up for 'expr']
Signed-off-by: Mike Lundy <mike@fluffypenguin.org>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The interactive version of rebase does all the operations on a detached
HEAD, so that after a successful rebase, <branch>@{1} is the pre-rebase
state. The reflogs of "HEAD" still show all the actions in detail.
This teaches the non-interactive version to do the same.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
recursive merge relies on Python, and we can't perform
rename-aware merges without the recursive merge. So bail out
before trying it.
The test won't work w/o recursive merge, either, so skip that,
too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
