{"thread":{"id":"33227","subject":"[BUG?] rebase -i: edit versus unmerged changes","startedAt":"2013-03-19T09:37:54Z","lastAt":"2013-03-24T05:13:15Z","messageCount":10,"participants":["Ramkumar Ramachandra","Andrew Wong","Jonathan Nieder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"211644","messageId":"CALkWK0n=fb_kq+Ed3rd9MhQUCHY3+_nj=zw4M+GmjbzEO56SOg@mail.gmail.com","threadId":"33227","inReplyTo":null,"subject":"[BUG?] rebase -i: edit versus unmerged changes","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-19T09:37:54Z","receivedAt":"2013-03-19T09:37:54Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI have the following instruction sheet:\n\n pick 2f7c86e remote.c: simplify a bit of code using git_config_string()\n pick c7f7ae4 remote.c: introduce a way to have different remotes for\nfetch/push\n edit 7038841 remote.c: introduce remote.pushdefault\n edit 73413b0 remote.c: introduce branch..pushremote\n pick 7f47687 WIP: fetch-push: write a test\n\nWhen I get to 7038841, I edit config.txt, stage the changes and commit\n--amend, before executing rebase --continue. When I get to 73413b0\n(the next commit), I get a conflict which is auto-resolved by rerere.\nSo, I just make further changes to config.txt, and commit --amend\nbefore executing rebase --continue as before. Unfortunately, this\nsquashes 73413b0 into 7038841, because the merge conflict requires a\ncommit to resolve the merge and pick the commit; this is different\nfrom commit --amend, which worked in the previous case, because the\ncommit was already picked.\n\nI know that this is expected behavior, but is there an easy way to get\nrid of this inconsistency? I'd ideally like everything to use the\nsequencer, and have uniform --continue/ --abort/ --skip semantics, but\nthat would require re-implementing all the shell commands in C unless\nwe can think of exposing a generic API using stdin or something. Does\nanyone have ideas in this direction?\n\nThanks.\n\nRam\n"},{"id":"211671","messageId":"CADeaMWoeRQBbrqLsfieKTE2rRbpzU-Hyp+mv-=CTj+=Znmf=Zw@mail.gmail.com","threadId":"33227","inReplyTo":"CALkWK0n=fb_kq+Ed3rd9MhQUCHY3+_nj=zw4M+GmjbzEO56SOg@mail.gmail.com","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Andrew Wong","fromEmail":"andrew.kw.w@gmail.com","sentAt":"2013-03-19T14:21:20Z","receivedAt":"2013-03-19T14:21:20Z","isPatch":false,"sender":{"key":"andrew.kw.w@gmail.com","avatar":"https://avatars.githubusercontent.com/u/489311?v=4"},"body":"On 3/19/13, Ramkumar Ramachandra wrote:\n> I know that this is expected behavior, but is there an easy way to get\n> rid of this inconsistency?\n\nYou can actually rely on \"rebase\" to run the appropriate command. In\nthe first edit commit (the_\nno conflict one), I usually run only \"git add\" to add my changes, then\njust run \"git rebase --cont\"._\nAnd \"rebase\" will recognize that I'm doing an \"edit\" and run \"git\ncommit --amend\" for me. For the\n\"unmerged case\", I'd do the same \"add and continue\", and \"rebase\" will\nrun \"git commit\" for__\nme.\n\nBy doing that, the two scenarios feel a bit more consistent.\n"},{"id":"211821","messageId":"CALkWK0mgX40oicqxnoa7M3NJP_k8jDrg7mVGyWrg5T+=iRtHQA@mail.gmail.com","threadId":"33227","inReplyTo":"CADeaMWoeRQBbrqLsfieKTE2rRbpzU-Hyp+mv-=CTj+=Znmf=Zw@mail.gmail.com","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-20T20:25:27Z","receivedAt":"2013-03-20T20:25:27Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Andrew Wong wrote:\n> On 3/19/13, Ramkumar Ramachandra wrote:\n>> I know that this is expected behavior, but is there an easy way to get\n>> rid of this inconsistency?\n>\n> You can actually rely on \"rebase\" to run the appropriate command.\n\nDidn't Junio explicitly mention that this is undesirable earlier (from\nthe point of view of `rebase -i` design)? The printed advice too,\nsays that you should use `commit --amend` to finish the job before\ninvoking --continue. Also IIRC, we don't allow --continue after\nstaging changes in the sequencer.\n"},{"id":"211823","messageId":"20130320204242.GA29311@google.com","threadId":"33227","inReplyTo":"CALkWK0mgX40oicqxnoa7M3NJP_k8jDrg7mVGyWrg5T+=iRtHQA@mail.gmail.com","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-20T20:42:42Z","receivedAt":"2013-03-20T20:42:42Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Andrew Wong wrote:\n\n>> You can actually rely on \"rebase\" to run the appropriate command.\n>\n> Didn't Junio explicitly mention that this is undesirable earlier (from\n> the point of view of `rebase -i` design)?\n\nI missed the earlier discussion. Does the documentation (e.g.,\ngit-rebase(1)) cover this? I can't think of any reason off-hand not to\nrely on the DWIMery involved in \"git rebase --continue\".\n\nCurious,\nJonathan\n"},{"id":"211826","messageId":"7vsj3pdcm5.fsf@alter.siamese.dyndns.org","threadId":"33227","inReplyTo":"CALkWK0mgX40oicqxnoa7M3NJP_k8jDrg7mVGyWrg5T+=iRtHQA@mail.gmail.com","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-20T20:45:22Z","receivedAt":"2013-03-20T20:45:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Andrew Wong wrote:\n>> On 3/19/13, Ramkumar Ramachandra wrote:\n>>> I know that this is expected behavior, but is there an easy way to get\n>>> rid of this inconsistency?\n>>\n>> You can actually rely on \"rebase\" to run the appropriate command.\n>\n> Didn't Junio explicitly mention that this is undesirable earlier (from\n> the point of view of `rebase -i` design)? \n\nI am sure it is my fault but my memory fails me. As Andrew\nmentioned, \"rebase --continue\" seemed to get this right.\n"},{"id":"211923","messageId":"CALkWK0kHFHtsy1Eh+jnY-JNSDUYd2xtiavhPNjaT8H3mJvYZkA@mail.gmail.com","threadId":"33227","inReplyTo":"7vsj3pdcm5.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-22T08:23:23Z","receivedAt":"2013-03-22T08:23:23Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Ramkumar Ramachandra writes:\n>\n>> Andrew Wong wrote:\n>>> On 3/19/13, Ramkumar Ramachandra wrote:\n>>>> I know that this is expected behavior, but is there an easy way to get\n>>>> rid of this inconsistency?\n>>>\n>>> You can actually rely on \"rebase\" to run the appropriate command.\n>>\n>> Didn't Junio explicitly mention that this is undesirable earlier (from\n>> the point of view of `rebase -i` design)?\n>\n> I am sure it is my fault but my memory fails me. As Andrew\n> mentioned, \"rebase --continue\" seemed to get this right.\n\nAfter digging through the list, I did manage to find Junio's original\nmessage I was referring to [1]. This, along with other discussions\nhas resulted in a sequencer with the Right (TM) design. I know I've\nbrought this up several times before and that it has gone nowhere, but\nI'd really to have that final 'git continue' in Git 2.0. Can someone\nattempt to break up the migration path into manageable logical steps\nthat we can start working on?\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/179304/focus=179383\n"},{"id":"211968","messageId":"20130322182550.GF12223@google.com","threadId":"33227","inReplyTo":"CALkWK0kHFHtsy1Eh+jnY-JNSDUYd2xtiavhPNjaT8H3mJvYZkA@mail.gmail.com","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-22T18:25:50Z","receivedAt":"2013-03-22T18:25:50Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> I'd really to have that final 'git continue' in Git 2.0. Can someone\n> attempt to break up the migration path into manageable logical steps\n> that we can start working on?\n\nIs there any deadline or migration path needed? Depending on the\ndesign, it might be possible to do without backward-incompatible\nchanges, meaning the migration path is \"whatever someone feels like\nimplementing first lands first\".\n\nHope that helps,\nJonathan\n"},{"id":"211979","messageId":"7vehf76uai.fsf@alter.siamese.dyndns.org","threadId":"33227","inReplyTo":"20130322182550.GF12223@google.com","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-22T20:42:13Z","receivedAt":"2013-03-22T20:42:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Ramkumar Ramachandra wrote:\n>\n>> I'd really to have that final 'git continue' in Git 2.0. Can someone\n>> attempt to break up the migration path into manageable logical steps\n>> that we can start working on?\n>\n> Is there any deadline or migration path needed? Depending on the\n> design, it might be possible to do without backward-incompatible\n> changes, meaning the migration path is \"whatever someone feels like\n> implementing first lands first\".\n\nFWIW, I am not convinced yet why we would even want \"git continue\"\nin the first place, so I won't be the one who would be suggesting a\nmigration path.\n"},{"id":"212050","messageId":"CALkWK0nspPEaA3BLjgV6Qv2UgXRbDft1d6SmRCiVNJoxpqLFwg@mail.gmail.com","threadId":"33227","inReplyTo":"7vehf76uai.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-23T12:51:22Z","receivedAt":"2013-03-23T12:51:22Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>\n>> Ramkumar Ramachandra wrote:\n>>\n>>> I'd really to have that final 'git continue' in Git 2.0. Can someone\n>>> attempt to break up the migration path into manageable logical steps\n>>> that we can start working on?\n>>\n>> Is there any deadline or migration path needed? Depending on the\n>> design, it might be possible to do without backward-incompatible\n>> changes, meaning the migration path is \"whatever someone feels like\n>> implementing first lands first\".\n>\n> FWIW, I am not convinced yet why we would even want \"git continue\"\n> in the first place, so I won't be the one who would be suggesting a\n> migration path.\n\nOkay, I'm confused now. You were the one who suggested a unified \"git\ncontinue\" in the first place, if my memory serves me right. Why are\nyou doubting it now?\n"},{"id":"212071","messageId":"7vhak14bys.fsf@alter.siamese.dyndns.org","threadId":"33227","inReplyTo":"CALkWK0nspPEaA3BLjgV6Qv2UgXRbDft1d6SmRCiVNJoxpqLFwg@mail.gmail.com","subject":"Re: [BUG?] rebase -i: edit versus unmerged changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-24T05:13:15Z","receivedAt":"2013-03-24T05:13:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n>\n>> FWIW, I am not convinced yet why we would even want \"git continue\"\n>> in the first place, so I won't be the one who would be suggesting a\n>> migration path.\n>\n> Okay, I'm confused now. You were the one who suggested a unified \"git\n> continue\" in the first place, if my memory serves me right. Why are\n> you doubting it now?\n\nAFAIR, the only thing I said about \"continue\" was that in a more\nrational future where many \"git frotz\" commands that can stop and\nask the user to help exist, after the user helps the command by\ncreating the desired outcome in the index, the way the user signals\nthat she is done helping would be \"git frotz --continue\", and the\n\"After helping 'git merge', conclude it with 'git commit'\" would be\nan odd-man-out, and adding 'git merge --continue' may not be a bad\nidea to make things more consistent. Originally the way to help\n\"am\" (with or without \"-3\") was to say \"am --resolved\", but that has\nlong been fixed to also take \"am --continue\".\n\nSo if you are adding \"git merge --continue\", that would be fine by\nme, but I never said \"git continue\" subcommand would make any sense\nat all.\n"}]}