From: Junio C Hamano <gitster@pobox.com>
To: しらいしななこ <nanako3@bluebottle.com>
Cc: git@vger.kernel.org
Subject: Re: [BUG?] "git rebase --interactive" forces me to edit message.
Date: Wed, 04 Jun 2008 21:14:02 -0700 [thread overview]
Message-ID: <7v3ans5xit.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 200806050358.m553wgK9013230@mi0.bluebottle.com
しらいしななこ <nanako3@bluebottle.com> 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
next prev parent reply other threads:[~2008-06-05 4:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 3:58 [BUG?] "git rebase --interactive" forces me to edit message しらいしななこ
2008-06-05 4:14 ` Junio C Hamano [this message]
2008-06-05 4:40 ` Johannes Schindelin
2008-06-05 4:38 ` Johannes Schindelin
2008-06-06 21:46 ` しらいしななこ
2008-06-06 23:21 ` Junio C Hamano
[not found] ` <200806062147.m56LlCOe030269@mi0.bluebottle.com>
2008-06-07 4:57 ` Johannes Schindelin
2008-06-07 6:53 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v3ans5xit.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=nanako3@bluebottle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox