[BUG?] "git rebase --interactive" forces me to edit message.

[BUG?] "git rebase --interactive" forces me to edit message.

[しらいしななこ]

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, first prepare a file with five lines and create an initial commit:

% git init
% cat file
1
2
3
4
5
% git add file
% git commit -m 'initial'
% git tag initial

Then edit the second line and replace "2" with "two", and commit.
Then edit the third line and replace "3" with "three", and commit.

Then say:

% git rebase --interactive initial

and reverse the first two lines.  It stops at the first commit that changes "3" to "three".

Resolve the conflicts by editing it so that it has "1 2 three 4 5", and say:
% git add file
% git rebase --continue

At this point, git opens vi and asks me to edit the message.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com/tag/4

Re: [BUG?] "git rebase --interactive" forces me to edit message.

[Junio C Hamano]

しらいしななこ <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
 

Re: [BUG?] "git rebase --interactive" forces me to edit message.

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 856 bytes --]

Hi,

On Thu, 5 Jun 2008, しらいしななこ wrote:

> 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?

No, it is intentional.

If you have to edit, because of conflicts, it may be because _part_ of the 
commit ended up in upstream already.

To remind the user that the commit message may need to be adjusted, rebase 
--interactive fires up the editor.

Yes, it happened to me.  Yes, the reminder was helpful.

Hth,
Dscho

Re: [BUG?] "git rebase --interactive" forces me to edit message.

[Johannes Schindelin]

Hi,

On Wed, 4 Jun 2008, Junio C Hamano wrote:

> 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

I guess with the recent changes, I do not count as author of rebase -i 
anymore.  Otherwise, I would say "NACK" for the reasons described in my 
other mail.

Ciao,
Dscho

Re: [BUG?] "git rebase --interactive" forces me to edit message.

[しらいしななこ]

Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:

> Hi,
>
> On Thu, 5 Jun 2008, しらいしななこ wrote:
>
>> 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?
>
> No, it is intentional.
>
> If you have to edit, because of conflicts, it may be because _part_ of the 
> commit ended up in upstream already.
>
> To remind the user that the commit message may need to be adjusted, rebase 
> --interactive fires up the editor.
>
> Yes, it happened to me.  Yes, the reminder was helpful.
>
> Hth,
> Dscho

Thank you very much.  I think I understand the problem better with your explanation (and much more detailed explanation from Junio).

But I started wondering (especially after read Junio's example) if you might have to stop and force edit the message even for commits you "pick", once you have a conflict.  The patch might not conflict, but  with your logic shouldn't you be given a chance to amend messages, now it was discovered that the upstream did change that overlaps what you did?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com/tag/4

Re: [BUG?] "git rebase --interactive" forces me to edit message.

[Junio C Hamano]

しらいしななこ  <nanako3@bluebottle.com> writes:

> But I started wondering (especially after read Junio's example) if you
> might have to stop and force edit the message even for commits you
> "pick", once you have a conflict.  The patch might not conflict, but
> with your logic shouldn't you be given a chance to amend messages, now
> it was discovered that the upstream did change that overlaps what you
> did?

[jc: again, linewrap X-<]

That may be true but at that point I would have to say that people should
always examine the resulting history anyway to see if they need to fix-up
mismerges (and mismerges do happen if the reordered patches have semantic
conflicts that do not appear as textual conflicts), and re-fix the
commits, perhaps using "rebase -i" on now linearlized history.  Forcing
every single patch to be committed by hand after a single conflict is
going a bit too far, I think.

Of course, you _can_ argue that forcing the patch that conflicted to be
committed by hand even when you merely asked to 'pick', not 'edit', is
going too far by the same logic, and I tend to agree with that.  The world
is not just black and white and that case certainly feels gray.

Re: [BUG?] "git rebase --interactive" forces me to edit message.

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1771 bytes --]

Hi,

On Sat, 7 Jun 2008, しらいしななこ wrote:

> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> 
> > On Thu, 5 Jun 2008, しらいしななこ wrote:
> >
> >> 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?
> >
> > No, it is intentional.
> >
> > If you have to edit, because of conflicts, it may be because _part_ of 
> > the commit ended up in upstream already.
> >
> > To remind the user that the commit message may need to be adjusted, 
> > rebase --interactive fires up the editor.
> >
> > Yes, it happened to me.  Yes, the reminder was helpful.
> 
> Thank you very much.  I think I understand the problem better with your 
> explanation (and much more detailed explanation from Junio).
> 
> But I started wondering (especially after read Junio's example) if you 
> might have to stop and force edit the message even for commits you 
> "pick", once you have a conflict.  The patch might not conflict, but 
> with your logic shouldn't you be given a chance to amend messages, now 
> it was discovered that the upstream did change that overlaps what you 
> did?

You do.  With a conflict, it stops.  If you do not commit, but only 
resolve the conflicts and add them to the index, then continue the rebase 
-i, it will ask you to commit.  Interactively.  (IOW an editor is fired 
up.)

Ciao,
Dscho

Re: [BUG?] "git rebase --interactive" forces me to edit message.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> But I started wondering (especially after read Junio's example) if you 
>> might have to stop and force edit the message even for commits you 
>> "pick", once you have a conflict.  The patch might not conflict, but 
>> with your logic shouldn't you be given a chance to amend messages, now 
>> it was discovered that the upstream did change that overlaps what you 
>> did?
>
> You do.  With a conflict, it stops.  If you do not commit, but only 
> resolve the conflicts and add them to the index, then continue the rebase 
> -i, it will ask you to commit.  Interactively.  (IOW an editor is fired 
> up.)

I might be misreading it, but my understanding of the scenario is:

 - you have pick A, pick B and pick C;
 - you reordered them to pick C, pick B and pick A;
 - the first one, pick C failed, and "add -u && rebase --continue" does
   ask for that pick C.

However, if neither pick B and pick A after that step has textual
conflicts, the command does not stop for them, and does not give you a
chance to adjust their potentially stale commit log messages.

I've already stated my position on this issue earlier in the thread.