{"thread":{"id":"54184","subject":"Aborting git rebase --edit-todo","startedAt":"2020-09-03T09:39:40Z","lastAt":"2020-09-06T21:52:34Z","messageCount":14,"participants":["Victor Toni","Junio C Hamano","Carlo Arenas","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"404962","messageId":"CAG0OSgeb0jcUmkjp+yzCPYkxQWCZFy3gYM9o7TfBGvtf4M08NQ@mail.gmail.com","threadId":"54184","inReplyTo":null,"subject":"Aborting git rebase --edit-todo","fromName":"Victor Toni","fromEmail":"victor.toni@gmail.com","sentAt":"2020-09-03T09:39:06Z","receivedAt":"2020-09-03T09:39:40Z","isPatch":false,"sender":{"key":"victor.toni@gmail.com","avatar":null},"body":"When doing a commit or choosing what to do for an interactive rebase\none can just wipe the whole content of the editor, save and close to\nabort the action.\nWhile doing a `git rebase --edit-todo` I came to the conclusion that I\nwould like to abort the edit and did the same. The final `git rebase\n--continue` got me rid of the rest of the commits...\n(Fortunately the \"missing\" commits could be rescued by looking into\n`.git/logs/HEAD` so thumbs up for that. )\nUnfortunately the behaviour of `--edit-todo` was a bit surprising and\nsomehow doesn't feel consistent with the other actions involving an\neditor.\n\nCan this be considered a bug?\n\nBest regards,\nVictor\n"},{"id":"404972","messageId":"xmqqa6y6ah8h.fsf@gitster.c.googlers.com","threadId":"54184","inReplyTo":"CAG0OSgeb0jcUmkjp+yzCPYkxQWCZFy3gYM9o7TfBGvtf4M08NQ@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-03T17:43:26Z","receivedAt":"2020-09-03T17:43:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Victor Toni writes:\n\n> When doing a commit or choosing what to do for an interactive rebase\n> one can just wipe the whole content of the editor, save and close to\n> abort the action.\n> While doing a `git rebase --edit-todo` I came to the conclusion that I\n> would like to abort the edit and did the same. The final `git rebase\n> --continue` got me rid of the rest of the commits...\n> (Fortunately the \"missing\" commits could be rescued by looking into\n> `.git/logs/HEAD` so thumbs up for that. )\n> Unfortunately the behaviour of `--edit-todo` was a bit surprising and\n> somehow doesn't feel consistent with the other actions involving an\n> editor.\n>\n> Can this be considered a bug?\n\nIt is rather unusual (or almost always wrong) to have a totally\nempty commit log or initial todo list, so it is understandable for\nGit in these situations to stop without doing anything further.\n\nThere is no other sensible interpretations of what you are telling\nGit to you by returning an empty buffer---it is extremely unlikely\nyou want to create a commit with no log message (without explicitly\nallowing it with --allow-empty-message, the command is likely to\nfail anyway), and it is extremely unlikely that you wanted to just\nreset the tip of the branch to the --onto commit.\n\nOnce an interactive rebase session has started and you are given the\nremainder of the steps to edit and you give an empty buffer back,\nhowever, there are two possible interpretations that are equally\nsensible, I would think.\n\n - One is that you are signaling that you are done with the rebase\n session and all the remaining commits are to be discarded. \n\n - The other is that you botched editing the todo list, and you wish\n Git to give you another chance to edit it again.\n\nI think the implementor chose the first interpretation. The \"drop\"\ninsn is a relatively recent invention, and back when it was missing\nfrom the vocabulary, I do not think it was possible to say \" discard\nall the rest\" without emptying the todo list, so that design is\nunderstandable.\n\nNow we have the \"drop\" verb, the latter interpretation becomes\npossible without making it impossible for the user to express the\nformer. It might be a good idea to\n\n (1) save away the original before allowing --edit-todo to edit,\n\n (2) open the editor, and\n\n (3) when getting an empty buffer back, go back to step (2) using\n the back-up made in step (1).\n\nEither way, the todo list editor buffer can have additional comment\ninstructing what happens when the buffer is emptied.\n\nI have no strong opinion on this one myself. Deferring to Dscho,\nwho may have a lot more to say on the design issue around this\nfeature than I do.\n\nThanks.\n"},{"id":"404976","messageId":"CAPUEspjKcQgLvVrJ2GroqYydNPksEziMgyceN-CFBFVgtngMuA@mail.gmail.com","threadId":"54184","inReplyTo":"xmqqa6y6ah8h.fsf@gitster.c.googlers.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2020-09-03T18:55:04Z","receivedAt":"2020-09-03T18:55:22Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Sep 3, 2020 at 10:47 AM Junio C Hamano wrote:\n\n> Now we have the \"drop\" verb, the latter interpretation becomes\n> possible without making it impossible for the user to express the\n> former.\n\nand for people that would like to enforce the use of the drop verb\nthere is configuration that prevents deleted lines to \"silently\"\ndropping commits since 5a5445d878 (rebase-interactive: warn if commit\nis dropped with `rebase --edit-todo', 2020-01-28) :\n\n rebase.missingCommitsCheck\n\nAFAIK the correct \"signal\" to abort is to instruct your editor to exit\nwith non zero (ex: in vi using :cq), but agree it could be\nconfusing or \"inconsistent\" and might be worth adding it a message at\nthe footer\n\nCarlo\n"},{"id":"404978","messageId":"CAG0OSgf9FsOpfOH+ErRTzMT333yDyZNthM8+7X3eRp=apRwJZg@mail.gmail.com","threadId":"54184","inReplyTo":"CAPUEspjKcQgLvVrJ2GroqYydNPksEziMgyceN-CFBFVgtngMuA@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Victor Toni","fromEmail":"victor.toni@gmail.com","sentAt":"2020-09-03T19:22:06Z","receivedAt":"2020-09-03T19:22:50Z","isPatch":false,"sender":{"key":"victor.toni@gmail.com","avatar":null},"body":"> > Now we have the \"drop\" verb, the latter interpretation becomes\n> > possible without making it impossible for the user to express the\n> > former.\n>\n> and for people that would like to enforce the use of the drop verb\n> there is configuration that prevents deleted lines to \"silently\"\n> dropping commits since 5a5445d878 (rebase-interactive: warn if commit\n> is dropped with `rebase --edit-todo', 2020-01-28) :\n>\n> rebase.missingCommitsCheck\n>\n\nDidn't know about that one, will add it right away to my .gitconfig. Thanks.\n\n> AFAIK the correct \"signal\" to abort is to instruct your editor to exit\n> with non zero (ex: in vi using :cq), but agree it could be\n> confusing or \"inconsistent\" and might be worth adding it a message at\n> the footer\n>\n\nThis sounds easier than it might be. On some machines I have (Git for)\nWindows and use a \"regular\" text editor which I guess I would have to\nkill to make it exit in a way to be recognized by git.\nEven when using Linux I never needed to make my editor exit with a non\nzero code. From a coding perspective this might work, from a usability\nperspective I really don't like it.\n\nVictor\n"},{"id":"404979","messageId":"CAG0OSgcUi6sKJQmUEd4-Lu5qAiQqKk7X7aSRvRtcBWkcKj4f1g@mail.gmail.com","threadId":"54184","inReplyTo":"xmqqa6y6ah8h.fsf@gitster.c.googlers.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Victor Toni","fromEmail":"victor.toni@gmail.com","sentAt":"2020-09-03T19:32:09Z","receivedAt":"2020-09-03T19:32:43Z","isPatch":false,"sender":{"key":"victor.toni@gmail.com","avatar":null},"body":"> It is rather unusual (or almost always wrong) to have a totally\n> empty commit log or initial todo list, so it is understandable for\n> Git in these situations to stop without doing anything further.\n>\n> There is no other sensible interpretations of what you are telling\n> Git to you by returning an empty buffer---it is extremely unlikely\n> you want to create a commit with no log message (without explicitly\n> allowing it with --allow-empty-message, the command is likely to\n> fail anyway), and it is extremely unlikely that you wanted to just\n> reset the tip of the branch to the --onto commit.\n>\n> Once an interactive rebase session has started and you are given the\n> remainder of the steps to edit and you give an empty buffer back,\n> however, there are two possible interpretations that are equally\n> sensible, I would think.\n>\n> - One is that you are signaling that you are done with the rebase\n> session and all the remaining commits are to be discarded.\n>\n> - The other is that you botched editing the todo list, and you wish\n> Git to give you another chance to edit it again.\n>\n> I think the implementor chose the first interpretation. The \"drop\"\n> insn is a relatively recent invention, and back when it was missing\n> from the vocabulary, I do not think it was possible to say \" discard\n> all the rest\" without emptying the todo list, so that design is\n> understandable.\n>\n> Now we have the \"drop\" verb, the latter interpretation becomes\n> possible without making it impossible for the user to express the\n> former. It might be a good idea to\n>\n> (1) save away the original before allowing --edit-todo to edit,\n>\n> (2) open the editor, and\n>\n> (3) when getting an empty buffer back, go back to step (2) using\n> the back-up made in step (1).\n>\n> Either way, the todo list editor buffer can have additional comment\n> instructing what happens when the buffer is emptied.\n>\n\nPersonally I would like to see your approach (1,2,3) implemented\nbecause it is not destructive. If the user wants to achieve something\ndifferent he can retry.\nOption / interpretation a)\n\n> - One is that you are signaling that you are done with the rebase\n> session and all the remaining commits are to be discarded.\n\nis more difficult to recover from. (I'm still thankful for `.git/logs/HEAD`)\n"},{"id":"404981","messageId":"CAPUEspgScq1ay7KgSBmgAW_8SAymWpydQm5gAO9WiTumtu-e8w@mail.gmail.com","threadId":"54184","inReplyTo":"CAG0OSgcUi6sKJQmUEd4-Lu5qAiQqKk7X7aSRvRtcBWkcKj4f1g@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2020-09-03T19:59:04Z","receivedAt":"2020-09-03T19:59:20Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Sep 3, 2020 at 12:36 PM Victor Toni wrote:\n>\n> is more difficult to recover from. (I'm still thankful for `.git/logs/HEAD`)\n\nanother command that might not be that well known and that will always\nrecover from a botched merge (or a rebase in this case) :\n\n $ git reset --hard ORIG_HEAD\n\nCarlo\n\nPS. `git reflog` might be also interesting; sorry if going slightly off topic\n"},{"id":"404982","messageId":"xmqq5z8uaatg.fsf@gitster.c.googlers.com","threadId":"54184","inReplyTo":"CAG0OSgf9FsOpfOH+ErRTzMT333yDyZNthM8+7X3eRp=apRwJZg@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-03T20:02:03Z","receivedAt":"2020-09-03T20:02:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Victor Toni writes:\n\n> Even when using Linux I never needed to make my editor exit with a non\n> zero code. From a coding perspective this might work, from a usability\n> perspective I really don't like it.\n\nI do not use --edit-todo myself so personally I do not care that\ndeeply either way, but I have to agree that it is not the most\nnatural UI to make your editor to exit with non-zero status to\nsignal something to the program that opened the editor.\n"},{"id":"404987","messageId":"CAG0OSgco0sRB=qXXfY2S2t_BdX9UpaOVxS3_VWyr5r6K+tjBOQ@mail.gmail.com","threadId":"54184","inReplyTo":"CAPUEspgScq1ay7KgSBmgAW_8SAymWpydQm5gAO9WiTumtu-e8w@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Victor Toni","fromEmail":"victor.toni@gmail.com","sentAt":"2020-09-03T21:07:38Z","receivedAt":"2020-09-03T21:08:11Z","isPatch":false,"sender":{"key":"victor.toni@gmail.com","avatar":null},"body":"On Do., 3. Sept. 2020 um 21:59 Uhr schrieb Carlo Arenas :\n>\n> On Thu, Sep 3, 2020 at 12:36 PM Victor Toni wrote:\n> >\n> > is more difficult to recover from. (I'm still thankful for `.git/logs/HEAD`)\n>\n> another command that might not be that well known and that will always\n> recover from a botched merge (or a rebase in this case) :\n>\n> $ git reset --hard ORIG_HEAD\n>\nI tried it on a backup copy of my repository (created directly after\nthe \"incident\").\nUnfortunately it would have missed two commits.\n\n> PS. `git reflog` might be also interesting; sorry if going slightly off topic\n\nThanks for that. Never used it before. git reflog would have helped\ndirectly since it shows the last real commit I did before messing\nthings up.\nFrom there it's a walk in the park.\n\nVictor\n"},{"id":"404988","messageId":"xmqqtuwe8t5s.fsf@gitster.c.googlers.com","threadId":"54184","inReplyTo":"CAG0OSgcUi6sKJQmUEd4-Lu5qAiQqKk7X7aSRvRtcBWkcKj4f1g@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-03T21:08:47Z","receivedAt":"2020-09-03T21:08:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Victor Toni writes:\n\n>> I think the implementor chose the first interpretation. The \"drop\"\n>> insn is a relatively recent invention, and back when it was missing\n>> from the vocabulary, I do not think it was possible to say \" discard\n>> all the rest\" without emptying the todo list, so that design is\n>> understandable.\n>>\n>> Now we have the \"drop\" verb, the latter interpretation becomes\n>> possible without making it impossible for the user to express the\n>> former. It might be a good idea to\n>>\n>> (1) save away the original before allowing --edit-todo to edit,\n>>\n>> (2) open the editor, and\n>>\n>> (3) when getting an empty buffer back, go back to step (2) using\n>> the back-up made in step (1).\n>>\n>> Either way, the todo list editor buffer can have additional comment\n>> instructing what happens when the buffer is emptied.\n>>\n> Personally I would like to see your approach (1,2,3) implemented\n> because it is not destructive. If the user wants to achieve something\n> different he can retry.\n\nObviously I agree that the approach would be nicer than the status\nquo. It would not be as trivial as a microproject, but would be a\ngood bite-sized starter-task for those aspiring developers who want\nto dip their toes in the water to start hacking on the codebase ;-)\n"},{"id":"404990","messageId":"CAG0OSgdT+ZCT0dN29A89XhWi65SFepwyGA0SoS22TYGrvNnWqw@mail.gmail.com","threadId":"54184","inReplyTo":"xmqqtuwe8t5s.fsf@gitster.c.googlers.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Victor Toni","fromEmail":"victor.toni@gmail.com","sentAt":"2020-09-03T21:21:59Z","receivedAt":"2020-09-03T21:22:35Z","isPatch":false,"sender":{"key":"victor.toni@gmail.com","avatar":null},"body":"Junio C Hamano writes:\n>\n> Victor Toni writes:\n>\n> >> I think the implementor chose the first interpretation. The \"drop\"\n> >> insn is a relatively recent invention, and back when it was missing\n> >> from the vocabulary, I do not think it was possible to say \" discard\n> >> all the rest\" without emptying the todo list, so that design is\n> >> understandable.\n> >>\n> >> Now we have the \"drop\" verb, the latter interpretation becomes\n> >> possible without making it impossible for the user to express the\n> >> former. It might be a good idea to\n> >>\n> >> (1) save away the original before allowing --edit-todo to edit,\n> >>\n> >> (2) open the editor, and\n> >>\n> >> (3) when getting an empty buffer back, go back to step (2) using\n> >> the back-up made in step (1).\n> >>\n> >> Either way, the todo list editor buffer can have additional comment\n> >> instructing what happens when the buffer is emptied.\n> >>\n> > Personally I would like to see your approach (1,2,3) implemented\n> > because it is not destructive. If the user wants to achieve something\n> > different he can retry.\n>\n> Obviously I agree that the approach would be nicer than the status\n> quo. It would not be as trivial as a microproject, but would be a\n> good bite-sized starter-task for those aspiring developers who want\n> to dip their toes in the water to start hacking on the codebase ;-)\n>\nNice try ;) Speaking of toes ... I'm currently involved in another\nproject from tip to toe.\nI would like to come back to your offer sometime next year when I've\ncompleted the other one.\nEspecially since I'd have to polish up my buried C skills... C didn't\nget GC lately, did it? ;)\n"},{"id":"405037","messageId":"nycvar.QRO.7.76.6.2009040729010.56@tvgsbejvaqbjf.bet","threadId":"54184","inReplyTo":"xmqqa6y6ah8h.fsf@gitster.c.googlers.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-09-04T05:32:11Z","receivedAt":"2020-09-04T13:56:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio & Victor,\n\nOn Thu, 3 Sep 2020, Junio C Hamano wrote:\n\n> Victor Toni writes:\n>\n> > When doing a commit or choosing what to do for an interactive rebase\n> > one can just wipe the whole content of the editor, save and close to\n> > abort the action.\n> > While doing a `git rebase --edit-todo` I came to the conclusion that I\n> > would like to abort the edit and did the same. The final `git rebase\n> > --continue` got me rid of the rest of the commits...\n> > (Fortunately the \"missing\" commits could be rescued by looking into\n> > `.git/logs/HEAD` so thumbs up for that. )\n> > Unfortunately the behaviour of `--edit-todo` was a bit surprising and\n> > somehow doesn't feel consistent with the other actions involving an\n> > editor.\n> >\n> > Can this be considered a bug?\n>\n> It is rather unusual (or almost always wrong) to have a totally\n> empty commit log or initial todo list, so it is understandable for\n> Git in these situations to stop without doing anything further.\n>\n> There is no other sensible interpretations of what you are telling\n> Git to you by returning an empty buffer---it is extremely unlikely\n> you want to create a commit with no log message (without explicitly\n> allowing it with --allow-empty-message, the command is likely to\n> fail anyway), and it is extremely unlikely that you wanted to just\n> reset the tip of the branch to the --onto commit.\n>\n> Once an interactive rebase session has started and you are given the\n> remainder of the steps to edit and you give an empty buffer back,\n> however, there are two possible interpretations that are equally\n> sensible, I would think.\n>\n> - One is that you are signaling that you are done with the rebase\n> session and all the remaining commits are to be discarded.\n>\n> - The other is that you botched editing the todo list, and you wish\n> Git to give you another chance to edit it again.\n>\n> I think the implementor chose the first interpretation. The \"drop\"\n> insn is a relatively recent invention, and back when it was missing\n> from the vocabulary, I do not think it was possible to say \" discard\n> all the rest\" without emptying the todo list, so that design is\n> understandable.\n>\n> Now we have the \"drop\" verb, the latter interpretation becomes\n> possible without making it impossible for the user to express the\n> former. It might be a good idea to\n>\n> (1) save away the original before allowing --edit-todo to edit,\n>\n> (2) open the editor, and\n>\n> (3) when getting an empty buffer back, go back to step (2) using\n> the back-up made in step (1).\n>\n> Either way, the todo list editor buffer can have additional comment\n> instructing what happens when the buffer is emptied.\n>\n> I have no strong opinion on this one myself. Deferring to Dscho,\n> who may have a lot more to say on the design issue around this\n> feature than I do.\n\nFirst of all, some historical background: the idea that deleting\neverything in the todo list aborts the rebase *predates* `git rebase\n--edit-todo` by quite a bit, in fact, that idea was implemented in either\nthe very first version of `git rebase -i` or at least very, very short\nthereafter.\n\nThis idea came from the fact that deleting the commit message would abort\na `git commit`.\n\nIn the meantime, `--edit-todo` is a thing (where this behavior makes a lot\nless sense), and `drop` is also a thing.\n\nI agree that it may be a good time to deprecate that behavior, after\nintroducing a new verb `abort` or something like that.\n\nCiao,\nDscho\n"},{"id":"405038","messageId":"nycvar.QRO.7.76.6.2009040742380.56@tvgsbejvaqbjf.bet","threadId":"54184","inReplyTo":"CAG0OSgdT+ZCT0dN29A89XhWi65SFepwyGA0SoS22TYGrvNnWqw@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-09-04T05:43:15Z","receivedAt":"2020-09-04T14:08:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Victor,\n\nOn Thu, 3 Sep 2020, Victor Toni wrote:\n\n> Junio C Hamano writes:\n> >\n> > Victor Toni writes:\n> >\n> > >> I think the implementor chose the first interpretation. The \"drop\"\n> > >> insn is a relatively recent invention, and back when it was missing\n> > >> from the vocabulary, I do not think it was possible to say \" discard\n> > >> all the rest\" without emptying the todo list, so that design is\n> > >> understandable.\n> > >>\n> > >> Now we have the \"drop\" verb, the latter interpretation becomes\n> > >> possible without making it impossible for the user to express the\n> > >> former. It might be a good idea to\n> > >>\n> > >> (1) save away the original before allowing --edit-todo to edit,\n> > >>\n> > >> (2) open the editor, and\n> > >>\n> > >> (3) when getting an empty buffer back, go back to step (2) using\n> > >> the back-up made in step (1).\n> > >>\n> > >> Either way, the todo list editor buffer can have additional comment\n> > >> instructing what happens when the buffer is emptied.\n> > >>\n> > > Personally I would like to see your approach (1,2,3) implemented\n> > > because it is not destructive. If the user wants to achieve something\n> > > different he can retry.\n> >\n> > Obviously I agree that the approach would be nicer than the status\n> > quo. It would not be as trivial as a microproject, but would be a\n> > good bite-sized starter-task for those aspiring developers who want\n> > to dip their toes in the water to start hacking on the codebase ;-)\n> >\n> Nice try ;) Speaking of toes ... I'm currently involved in another\n> project from tip to toe.\n> I would like to come back to your offer sometime next year when I've\n> completed the other one.\n\nSure. I expect this project to wait quite patiently for you to come back\nnext year ;-)\n\nCiao,\nDscho\n\n> Especially since I'd have to polish up my buried C skills... C didn't\n> get GC lately, did it? ;)\n>\n"},{"id":"405039","messageId":"nycvar.QRO.7.76.6.2009040734130.56@tvgsbejvaqbjf.bet","threadId":"54184","inReplyTo":"CAG0OSgcUi6sKJQmUEd4-Lu5qAiQqKk7X7aSRvRtcBWkcKj4f1g@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-09-04T05:42:29Z","receivedAt":"2020-09-04T14:08:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Victor,\n\nOn Thu, 3 Sep 2020, Victor Toni wrote:\n\n> > It is rather unusual (or almost always wrong) to have a totally\n> > empty commit log or initial todo list, so it is understandable for\n> > Git in these situations to stop without doing anything further.\n> >\n> > There is no other sensible interpretations of what you are telling\n> > Git to you by returning an empty buffer---it is extremely unlikely\n> > you want to create a commit with no log message (without explicitly\n> > allowing it with --allow-empty-message, the command is likely to\n> > fail anyway), and it is extremely unlikely that you wanted to just\n> > reset the tip of the branch to the --onto commit.\n> >\n> > Once an interactive rebase session has started and you are given the\n> > remainder of the steps to edit and you give an empty buffer back,\n> > however, there are two possible interpretations that are equally\n> > sensible, I would think.\n> >\n> > - One is that you are signaling that you are done with the rebase\n> > session and all the remaining commits are to be discarded.\n> >\n> > - The other is that you botched editing the todo list, and you wish\n> > Git to give you another chance to edit it again.\n> >\n> > I think the implementor chose the first interpretation. The \"drop\"\n> > insn is a relatively recent invention, and back when it was missing\n> > from the vocabulary, I do not think it was possible to say \" discard\n> > all the rest\" without emptying the todo list, so that design is\n> > understandable.\n> >\n> > Now we have the \"drop\" verb, the latter interpretation becomes\n> > possible without making it impossible for the user to express the\n> > former. It might be a good idea to\n> >\n> > (1) save away the original before allowing --edit-todo to edit,\n\nWe already do that:\nhttps://github.com/git/git/blob/v2.28.0/rebase-interactive.c#L113-L115\n\n> >\n> > (2) open the editor, and\n> >\n> > (3) when getting an empty buffer back, go back to step (2) using\n> > the back-up made in step (1).\n\nYes, and we can claim that this is a bug fix to avoid having to respect a\ndeprecation phase.\n\n> >\n> > Either way, the todo list editor buffer can have additional comment\n> > instructing what happens when the buffer is emptied.\n> >\n>\n> Personally I would like to see your approach (1,2,3) implemented\n> because it is not destructive. If the user wants to achieve something\n> different he\n\nor she, or they,\n\n> can retry.\n> Option / interpretation a)\n>\n> > - One is that you are signaling that you are done with the rebase\n> > session and all the remaining commits are to be discarded.\n>\n> is more difficult to recover from. (I'm still thankful for `.git/logs/HEAD`)\n\nIndeed, it is pretty tedious to recover from when you can originally made\nedits to the todo list that you then accidentally discarded.\n\nCiao,\nDscho\n"},{"id":"405100","messageId":"xmqqft7u4lpf.fsf@gitster.c.googlers.com","threadId":"54184","inReplyTo":"CAG0OSgdT+ZCT0dN29A89XhWi65SFepwyGA0SoS22TYGrvNnWqw@mail.gmail.com","subject":"Re: Aborting git rebase --edit-todo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-06T21:52:28Z","receivedAt":"2020-09-06T21:52:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Victor Toni writes:\n\n> Junio C Hamano writes:\n>>\n>> Victor Toni writes:\n>>\n>> > Personally I would like to see your approach (1,2,3) implemented\n>> > because it is not destructive. If the user wants to achieve something\n>> > different he can retry.\n>>\n>> Obviously I agree that the approach would be nicer than the status\n>> quo. It would not be as trivial as a microproject, but would be a\n>> good bite-sized starter-task for those aspiring developers who want\n>> to dip their toes in the water to start hacking on the codebase ;-)\n>>\n> Nice try ;)\n\nFor the record I didn't try _you_.\n\nI was writing for general audience, among which there are aspiring\ndevelopers seeking a starter-task. Whether you are part of that\naudience was immaterial (even though it would have been nice if you\nwere) ;-).\n\nThanks.\n\n\n\n"}]}