path: root/t/
diff options
authorPhillip Wood <>2018-06-19 12:46:51 (GMT)
committerJunio C Hamano <>2018-06-19 17:26:41 (GMT)
commita9279c678588a12485a8afa424036bdb5ad0534d (patch)
treebdb251983c53f99d49964b0fb8141e6570d68a5e /t/
parentf0ac6e39433c1d7e9339207aa4d01e9bf7a05b8a (diff)
sequencer: do not squash 'reword' commits when we hit conflicts
Ever since commit 18633e1a22 ("rebase -i: use the rebase--helper builtin", 2017-02-09), when a commit marked as 'reword' in an interactive rebase has conflicts and fails to apply, when the rebase is resumed that commit will be squashed into its parent with its commit message taken. The issue can be understood better by looking at commit 56dc3ab04b ("sequencer (rebase -i): implement the 'edit' command", 2017-01-02), which introduced error_with_patch() for the edit command. For the edit command, it needs to stop the rebase whether or not the patch applies cleanly. If the patch does apply cleanly, then when it resumes it knows it needs to amend all changes into the previous commit. If it does not apply cleanly, then the changes should not be amended. Thus, it passes !res (success of applying the 'edit' commit) to error_with_patch() for the to_amend flag. The problematic line of code actually came from commit 04efc8b57c ("sequencer (rebase -i): implement the 'reword' command", 2017-01-02). Note that to get to this point in the code: * !!res (i.e. patch application failed) * item->command < TODO_SQUASH * item->command != TODO_EDIT * !is_fixup(item->command) [i.e. not squash or fixup] So that means this can only be a failed patch application that is either a pick, revert, or reword. We only need to amend HEAD when rewording the root commit or a commit that has been fast-forwarded, for any of the other cases we want a new commit, so we should not set the to_amend flag. Helped-by: Johannes Schindelin <> Original-patch-by: Elijah Newren <> Signed-off-by: Phillip Wood <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 't/')
0 files changed, 0 insertions, 0 deletions