しらいしななこ <nanako3@xxxxxxxxxxxxxx> writes: > When an interactive rebase stops because of conflicts in a commit marked > with pick, the user must edit the file to resolve them, run "git add", > and run "git rebase --continue". It then opens vi and asks the user to > edit the message. If I told the command to edit, I think it is OK to > start vi, but when I am just picking the commit, I should be able to use > the message from the original commit without having to view nor edit nor > save it first. Is this a bug? > > To reproduce this,... [jc: I rewrapped your message above, but could you set your MUA to wrap lines at reasonable length on your end please?] It is debatable if this is a "bug". In the simplified example you presented as the reproduction recipe, updating the second and the third lines are truly independent and the reason of the conflict is merely that the commits unfortunately touched an area physically near-by, and I sympathize with you that it is irritating to see the editor, because in such a case it feels that there is absolutely no reason to change the log message. However, the edit you had to make during the conflict resolution may have involved more than just the simplest textual merge in the real life. Suppose your "replace 2 with two" were some bugfix, and your "replace 3 with three" were some infrastructure change. When hoisting the latter change up so that it comes early in the series, you may not have to update its log message. But the other patch (bugfix) might have to be done differently on top of the updated infrastructure, exactly because the code it touched now works differently --- a different fix may be needed, and that will be how the result of conflict resolution would look like. Now, the original "bugfix" commit might have said "When X is asked, it was shown twice because Y did Z without taking into account that W and V in the earlier codepath already have duplicated the data". But the infrastructure change may have changed the codepath in such a way that W does not happen (but V still does), and you may need a different message. So you do want to review and fix the message in such a case. For that matter, the original "infrastructure change" commit may well have said "With this change, because W does not happen anymore, half of the fix of the previous commit becomes unnecessary, but that is a separate topic and I did not touch that part. Leaving that fix in does not hurt, at least for now". You would want to reword that if that commit comes first and then fix comes next. Having said that, this patch should "fix" it, I think. git-rebase--interactive.sh | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 0ca986f..a6b6c9e 100755 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -390,11 +390,14 @@ do die "Cannot find the author identity" if test -f "$DOTEST"/amend then + do_edit=-e git reset --soft HEAD^ || die "Cannot rewind the HEAD" + else + do_edit= fi export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE && - git commit --no-verify -F "$DOTEST"/message -e || + git commit --no-verify -F "$DOTEST"/message $do_edit || die "Could not commit staged changes." fi -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
