{"thread":{"id":"13806","subject":"[BUG?] \"git rebase --interactive\" forces me to edit message.","startedAt":"2008-06-05T03:58:20Z","lastAt":"2008-06-07T06:53:20Z","messageCount":8,"participants":["しらいしななこ","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"78691","messageId":"200806050358.m553wgK9013230@mi0.bluebottle.com","threadId":"13806","inReplyTo":null,"subject":"[BUG?] \"git rebase --interactive\" forces me to edit message.","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2008-06-05T03:58:20Z","receivedAt":"2008-06-05T03:58:20Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"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?\n\nTo reproduce this, first prepare a file with five lines and create an initial commit:\n\n% git init\n% cat file\n1\n2\n3\n4\n5\n% git add file\n% git commit -m 'initial'\n% git tag initial\n\nThen edit the second line and replace \"2\" with \"two\", and commit.\nThen edit the third line and replace \"3\" with \"three\", and commit.\n\nThen say:\n\n% git rebase --interactive initial\n\nand reverse the first two lines.  It stops at the first commit that changes \"3\" to \"three\".\n\nResolve the conflicts by editing it so that it has \"1 2 three 4 5\", and say:\n% git add file\n% git rebase --continue\n\nAt this point, git opens vi and asks me to edit the message.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nFinally - A spam blocker that actually works.\nhttp://www.bluebottle.com/tag/4\n"},{"id":"78694","messageId":"7v3ans5xit.fsf@gitster.siamese.dyndns.org","threadId":"13806","inReplyTo":"200806050358.m553wgK9013230@mi0.bluebottle.com","subject":"Re: [BUG?] \"git rebase --interactive\" forces me to edit message.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-05T04:14:02Z","receivedAt":"2008-06-05T04:14:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"しらいしななこ <nanako3@bluebottle.com> writes:\n\n> When an interactive rebase stops because of conflicts in a commit marked\n> with pick, the user must edit the file to resolve them, run \"git add\",\n> and run \"git rebase --continue\".  It then opens vi and asks the user to\n> edit the message.  If I told the command to edit, I think it is OK to\n> start vi, but when I am just picking the commit, I should be able to use\n> the message from the original commit without having to view nor edit nor\n> save it first. Is this a bug?\n>\n> To reproduce this,...\n\n[jc: I rewrapped your message above, but could you set your MUA to wrap\nlines at reasonable length on your end please?]\n\nIt is debatable if this is a \"bug\".  In the simplified example you\npresented as the reproduction recipe, updating the second and the third\nlines are truly independent and the reason of the conflict is merely that\nthe commits unfortunately touched an area physically near-by, and I\nsympathize with you that it is irritating to see the editor, because in\nsuch a case it feels that there is absolutely no reason to change the log\nmessage.\n\nHowever, the edit you had to make during the conflict resolution may have\ninvolved more than just the simplest textual merge in the real life.\n\nSuppose your \"replace 2 with two\" were some bugfix, and your \"replace 3\nwith three\" were some infrastructure change.  When hoisting the latter\nchange up so that it comes early in the series, you may not have to update\nits log message.  But the other patch (bugfix) might have to be done\ndifferently on top of the updated infrastructure, exactly because the code\nit touched now works differently --- a different fix may be needed, and\nthat will be how the result of conflict resolution would look like.\n\nNow, the original \"bugfix\" commit might have said \"When X is asked, it was\nshown twice because Y did Z without taking into account that W and V in\nthe earlier codepath already have duplicated the data\".\n\nBut the infrastructure change may have changed the codepath in such a way\nthat W does not happen (but V still does), and you may need a different\nmessage.  So you do want to review and fix the message in such a case.\n\nFor that matter, the original \"infrastructure change\" commit may well have\nsaid \"With this change, because W does not happen anymore, half of the fix\nof the previous commit becomes unnecessary, but that is a separate topic\nand I did not touch that part.  Leaving that fix in does not hurt, at\nleast for now\".  You would want to reword that if that commit comes first\nand then fix comes next.\n\nHaving said that, this patch should \"fix\" it, I think.\n\n git-rebase--interactive.sh |    5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 0ca986f..a6b6c9e 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -390,11 +390,14 @@ do\n \t\t\t\tdie \"Cannot find the author identity\"\n \t\t\tif test -f \"$DOTEST\"/amend\n \t\t\tthen\n+\t\t\t\tdo_edit=-e\n \t\t\t\tgit reset --soft HEAD^ ||\n \t\t\t\tdie \"Cannot rewind the HEAD\"\n+\t\t\telse\n+\t\t\t\tdo_edit=\n \t\t\tfi\n \t\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n-\t\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n+\t\t\tgit commit --no-verify -F \"$DOTEST\"/message $do_edit ||\n \t\t\tdie \"Could not commit staged changes.\"\n \t\tfi\n \n"},{"id":"78698","messageId":"alpine.DEB.1.00.0806050536380.21190@racer","threadId":"13806","inReplyTo":"200806050358.m553wgK9013230@mi0.bluebottle.com","subject":"Re: [BUG?] \"git rebase --interactive\" forces me to edit message.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-05T04:38:58Z","receivedAt":"2008-06-05T04:38:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 5 Jun 2008, しらいしななこ wrote:\n\n> When an interactive rebase stops because of conflicts in a commit marked \n> with pick, the user must edit the file to resolve them, run \"git add\", \n> and run \"git rebase --continue\".  It then opens vi and asks the user to \n> edit the message.  If I told the command to edit, I think it is OK to \n> start vi, but when I am just picking the commit, I should be able to use \n> the message from the original commit without having to view nor edit nor \n> save it first. Is this a bug?\n\nNo, it is intentional.\n\nIf you have to edit, because of conflicts, it may be because _part_ of the \ncommit ended up in upstream already.\n\nTo remind the user that the commit message may need to be adjusted, rebase \n--interactive fires up the editor.\n\nYes, it happened to me.  Yes, the reminder was helpful.\n\nHth,\nDscho\n"},{"id":"78699","messageId":"alpine.DEB.1.00.0806050539360.21190@racer","threadId":"13806","inReplyTo":"7v3ans5xit.fsf@gitster.siamese.dyndns.org","subject":"Re: [BUG?] \"git rebase --interactive\" forces me to edit message.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-05T04:40:48Z","receivedAt":"2008-06-05T04:40:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 4 Jun 2008, Junio C Hamano wrote:\n\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index 0ca986f..a6b6c9e 100755\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -390,11 +390,14 @@ do\n>  \t\t\t\tdie \"Cannot find the author identity\"\n>  \t\t\tif test -f \"$DOTEST\"/amend\n>  \t\t\tthen\n> +\t\t\t\tdo_edit=-e\n>  \t\t\t\tgit reset --soft HEAD^ ||\n>  \t\t\t\tdie \"Cannot rewind the HEAD\"\n> +\t\t\telse\n> +\t\t\t\tdo_edit=\n>  \t\t\tfi\n>  \t\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n> -\t\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n> +\t\t\tgit commit --no-verify -F \"$DOTEST\"/message $do_edit ||\n>  \t\t\tdie \"Could not commit staged changes.\"\n>  \t\tfi\n\nI guess with the recent changes, I do not count as author of rebase -i \nanymore.  Otherwise, I would say \"NACK\" for the reasons described in my \nother mail.\n\nCiao,\nDscho\n"},{"id":"78961","messageId":"200806062147.m56LlCOd030269@mi0.bluebottle.com","threadId":"13806","inReplyTo":"alpine.DEB.1.00.0806050536380.21190@racer","subject":"Re: [BUG?] \"git rebase --interactive\" forces me to edit message.","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2008-06-06T21:46:33Z","receivedAt":"2008-06-06T21:46:33Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n\n> Hi,\n>\n> On Thu, 5 Jun 2008, しらいしななこ wrote:\n>\n>> When an interactive rebase stops because of conflicts in a commit marked \n>> with pick, the user must edit the file to resolve them, run \"git add\", \n>> and run \"git rebase --continue\".  It then opens vi and asks the user to \n>> edit the message.  If I told the command to edit, I think it is OK to \n>> start vi, but when I am just picking the commit, I should be able to use \n>> the message from the original commit without having to view nor edit nor \n>> save it first. Is this a bug?\n>\n> No, it is intentional.\n>\n> If you have to edit, because of conflicts, it may be because _part_ of the \n> commit ended up in upstream already.\n>\n> To remind the user that the commit message may need to be adjusted, rebase \n> --interactive fires up the editor.\n>\n> Yes, it happened to me.  Yes, the reminder was helpful.\n>\n> Hth,\n> Dscho\n\nThank you very much.  I think I understand the problem better with your explanation (and much more detailed explanation from Junio).\n\nBut 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?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nFinally - A spam blocker that actually works.\nhttp://www.bluebottle.com/tag/4\n"},{"id":"78981","messageId":"7vzlpyqhdf.fsf@gitster.siamese.dyndns.org","threadId":"13806","inReplyTo":"200806062147.m56LlCOd030269@mi0.bluebottle.com","subject":"Re: [BUG?] \"git rebase --interactive\" forces me to edit message.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-06T23:21:48Z","receivedAt":"2008-06-06T23:21:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"しらいしななこ  <nanako3@bluebottle.com> writes:\n\n> But I started wondering (especially after read Junio's example) if you\n> might have to stop and force edit the message even for commits you\n> \"pick\", once you have a conflict.  The patch might not conflict, but\n> with your logic shouldn't you be given a chance to amend messages, now\n> it was discovered that the upstream did change that overlaps what you\n> did?\n\n[jc: again, linewrap X-<]\n\nThat may be true but at that point I would have to say that people should\nalways examine the resulting history anyway to see if they need to fix-up\nmismerges (and mismerges do happen if the reordered patches have semantic\nconflicts that do not appear as textual conflicts), and re-fix the\ncommits, perhaps using \"rebase -i\" on now linearlized history.  Forcing\nevery single patch to be committed by hand after a single conflict is\ngoing a bit too far, I think.\n\nOf course, you _can_ argue that forcing the patch that conflicted to be\ncommitted by hand even when you merely asked to 'pick', not 'edit', is\ngoing too far by the same logic, and I tend to agree with that.  The world\nis not just black and white and that case certainly feels gray.\n"},{"id":"79014","messageId":"alpine.DEB.1.00.0806070556030.1783@racer","threadId":"13806","inReplyTo":"200806062147.m56LlCOe030269@mi0.bluebottle.com","subject":"Re: [BUG?] \"git rebase --interactive\" forces me to edit message.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-07T04:57:30Z","receivedAt":"2008-06-07T04:57:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 7 Jun 2008, しらいしななこ wrote:\n\n> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:\n> \n> > On Thu, 5 Jun 2008, しらいしななこ wrote:\n> >\n> >> When an interactive rebase stops because of conflicts in a commit \n> >> marked with pick, the user must edit the file to resolve them, run \n> >> \"git add\", and run \"git rebase --continue\".  It then opens vi and \n> >> asks the user to edit the message.  If I told the command to edit, I \n> >> think it is OK to start vi, but when I am just picking the commit, I \n> >> should be able to use the message from the original commit without \n> >> having to view nor edit nor save it first. Is this a bug?\n> >\n> > No, it is intentional.\n> >\n> > If you have to edit, because of conflicts, it may be because _part_ of \n> > the commit ended up in upstream already.\n> >\n> > To remind the user that the commit message may need to be adjusted, \n> > rebase --interactive fires up the editor.\n> >\n> > Yes, it happened to me.  Yes, the reminder was helpful.\n> \n> Thank you very much.  I think I understand the problem better with your \n> explanation (and much more detailed explanation from Junio).\n> \n> But I started wondering (especially after read Junio's example) if you \n> might have to stop and force edit the message even for commits you \n> \"pick\", once you have a conflict.  The patch might not conflict, but \n> with your logic shouldn't you be given a chance to amend messages, now \n> it was discovered that the upstream did change that overlaps what you \n> did?\n\nYou do.  With a conflict, it stops.  If you do not commit, but only \nresolve the conflicts and add them to the index, then continue the rebase \n-i, it will ask you to commit.  Interactively.  (IOW an editor is fired \nup.)\n\nCiao,\nDscho\n"},{"id":"79018","messageId":"7vabhxpwgv.fsf@gitster.siamese.dyndns.org","threadId":"13806","inReplyTo":"alpine.DEB.1.00.0806070556030.1783@racer","subject":"Re: [BUG?] \"git rebase --interactive\" forces me to edit message.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-07T06:53:20Z","receivedAt":"2008-06-07T06:53:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> But I started wondering (especially after read Junio's example) if you \n>> might have to stop and force edit the message even for commits you \n>> \"pick\", once you have a conflict.  The patch might not conflict, but \n>> with your logic shouldn't you be given a chance to amend messages, now \n>> it was discovered that the upstream did change that overlaps what you \n>> did?\n>\n> You do.  With a conflict, it stops.  If you do not commit, but only \n> resolve the conflicts and add them to the index, then continue the rebase \n> -i, it will ask you to commit.  Interactively.  (IOW an editor is fired \n> up.)\n\nI might be misreading it, but my understanding of the scenario is:\n\n - you have pick A, pick B and pick C;\n - you reordered them to pick C, pick B and pick A;\n - the first one, pick C failed, and \"add -u && rebase --continue\" does\n   ask for that pick C.\n\nHowever, if neither pick B and pick A after that step has textual\nconflicts, the command does not stop for them, and does not give you a\nchance to adjust their potentially stale commit log messages.\n\nI've already stated my position on this issue earlier in the thread.\n"}]}