{"thread":{"id":"61494","subject":"[Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","startedAt":"2024-05-16T19:22:00Z","lastAt":"2024-05-17T17:04:47Z","messageCount":9,"participants":["Junio C Hamano","Sean Allred","Patrick Steinhardt","Dragan Simic","Marc Branchaud"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"494911","messageId":"xmqqy189o94c.fsf@gitster.g","threadId":"61494","inReplyTo":null,"subject":"[Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-05-16T19:21:55Z","receivedAt":"2024-05-16T19:22:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"What should happen when I turn \"pick\" to \"edit\" in a \"rebase -i\"\nsession, check what got checked out in the working tree, find it\nsatisfactory and decide not to make any change to the files, and say\n\"rebase --continue\"?\n\nThe current implementation seems to just move to the next step,\nwithout offering a chance to edit the log message. I do not know\noffhand if this is something we changed recently, or if it has been\nthat way forever.\n\nI personally found this a bit unintuitive, because in my metal\nmodel, \"reword\" is a mere subset of \"edit\": the latter would give me\nchances to change both the contents and the log, while the former\nonly would offer me a chance to change the log.\n\nBut the actual behaviour does not match that mental model. \"edit\"\nis purely about editing the worktree files, and only if files (hence\nthe tree recorded) are modified, a chance to edit the log is offered\nto adjust the message to what the new tree brings on top of the\nparent commit.\n\nOf course, we can work it around with \"git rebase --edit-todo\"\nbefore saying \"git rebase --continue\". But the current behaviour\nsomehow feels optimized for a wrong case. Admittedly, it is logical\nthat it does not offer a chance to edit the log message if we did\nnot make any change to the working tree. After all, the reason why\nit may become necessary to edit the log is because the user made\nsome changes to the tree in the first place. And by not opening the\neditor, only to close it without making any change, the command is\nsaving the user some keystrokes.\n\nBut given that saying \"edit\" and not making any changes is a rare\ncase, it feels wrong thing to optimize for.\n\nAnyway.\n"},{"id":"494916","messageId":"m0seyhs8o2.fsf@epic96565.epic.com","threadId":"61494","inReplyTo":"xmqqy189o94c.fsf@gitster.g","subject":"Re: [Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Sean Allred","fromEmail":"allred.sean@gmail.com","sentAt":"2024-05-16T22:18:05Z","receivedAt":"2024-05-16T22:18:07Z","isPatch":false,"sender":{"key":"allred.sean@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2082195?v=4"},"body":"Junio C Hamano writes:\n> I personally found this a bit unintuitive, because in my metal\n> model, \"reword\" is a mere subset of \"edit\": the latter would give me\n> chances to change both the contents and the log, while the former\n> only would offer me a chance to change the log.\n\nMy mental model is not quite the same, interestingly: 'reword' and\n'edit' are not-quite-orthogonal, not-quite-parallel in terms of intent.\nIn 'reword', I know that I just care about the log. In 'edit', I don't\nknow *what* I'm going to do -- in fact, my mental model is more friendly\nto the idea that 'edit' => 'pick then break'. This of course may be a\nmental model learned from the observed behavior and not conceived from\nthe ideal behavior.\n\nMy 2c: in the case where you're changing the tree, you will already be\nprompted to change the log. It appears the assumption is that if you do\nnot change tree, you will not need to change the log.\n\nThis assumption holds true for me, but my workflow is generally to get\neach commit's patches into the desired state and only *then* spend some\nquality time with my messages. That's certainly not the only workflow,\nthough.\n\n> After all, the reason why it may become necessary to edit the log is\n> because the user made some changes to the tree in the first place. And\n> by not opening the editor, only to close it without making any change,\n> the command is saving the user some keystrokes.\n\n...and you seem to be on the same lines of thinking as I am. Playing\ndevil's advocate a bit: there are certainly other cases in Git where the\neditor pops open and I have muscle memory to close it. I wish I could\nrecall in this moment where those cases were, but I don't know that\navoiding an invocation of the editor is a good reason not to invoke the\neditor if that's the Right(tm) thing to do -- that seems to be a\ncircular argument.\n\nSetting aside the obvious reality that an actual change here could have\npretty serious UX considerations for folks with muscle-memory, what in\nyour opinion would be the right thing to do? Why? Are rebase commands\n'shortcuts' or are they intended to be orthogonal? Do they have designed\npurposes?\n\nI'm wondering if you can tease out what the 'ideal' state looks like to\nyou, then you can identify what if anything there is to be done about\nit.\n\n-Sean\n\n-- \nSean Allred\n"},{"id":"494933","messageId":"xmqqmsoonccd.fsf@gitster.g","threadId":"61494","inReplyTo":"m0seyhs8o2.fsf@epic96565.epic.com","subject":"Re: [Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-05-17T07:09:54Z","receivedAt":"2024-05-17T07:09:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean Allred writes:\n\n> Setting aside the obvious reality that an actual change here could have\n> pretty serious UX considerations for folks with muscle-memory, what in\n> your opinion would be the right thing to do? Why? Are rebase commands\n> 'shortcuts' or are they intended to be orthogonal? Do they have designed\n> purposes?\n>\n> I'm wondering if you can tease out what the 'ideal' state looks like to\n> you, then you can identify what if anything there is to be done about\n> it.\n\nOh, it would be very simple.\n\nIf I say \"edit\", whether I made a tree change or not, I want to get\nan editor when I said \"rebase --continue\". If I say \"reword\", I\nwant to get an editor _without_ having a chance to muck with the\ntree status. That would be the \"ideal\" behaviour, iow, the \"mental\nmodel\" is just \"edit\" gives the users a chance to edit both trees\n(by first giving control back to a shell prompt) and the log message\n(by opening the editor upon \"--continue\"), while \"reword\" is only\nabout the message so does not give shell prompt back to the user\n(unless absolutely necessary, that is. If the \"reword\" were to\nconflict due to tree changes in earlier steps, it would need to give\ncontrol back to a shell prompt to ask the user's help to resolve the\nconflict. It is just that when there is no need to edit the tree\notherwise, that is skipped).\n\n"},{"id":"494934","messageId":"ZkcH-LAkLkf_wvfq@tanuki","threadId":"61494","inReplyTo":"xmqqmsoonccd.fsf@gitster.g","subject":"Re: [Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-05-17T07:32:08Z","receivedAt":"2024-05-17T07:32:14Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, May 17, 2024 at 12:09:54AM -0700, Junio C Hamano wrote:\n> Sean Allred writes:\n> \n> > Setting aside the obvious reality that an actual change here could have\n> > pretty serious UX considerations for folks with muscle-memory, what in\n> > your opinion would be the right thing to do? Why? Are rebase commands\n> > 'shortcuts' or are they intended to be orthogonal? Do they have designed\n> > purposes?\n> >\n> > I'm wondering if you can tease out what the 'ideal' state looks like to\n> > you, then you can identify what if anything there is to be done about\n> > it.\n> \n> Oh, it would be very simple.\n> \n> If I say \"edit\", whether I made a tree change or not, I want to get\n> an editor when I said \"rebase --continue\". If I say \"reword\", I\n> want to get an editor _without_ having a chance to muck with the\n> tree status. That would be the \"ideal\" behaviour, iow, the \"mental\n> model\" is just \"edit\" gives the users a chance to edit both trees\n> (by first giving control back to a shell prompt) and the log message\n> (by opening the editor upon \"--continue\"), while \"reword\" is only\n> about the message so does not give shell prompt back to the user\n> (unless absolutely necessary, that is. If the \"reword\" were to\n> conflict due to tree changes in earlier steps, it would need to give\n> control back to a shell prompt to ask the user's help to resolve the\n> conflict. It is just that when there is no need to edit the tree\n> otherwise, that is skipped).\n\nI quite frequently use \"edit\" just to inspect commits, stop at random\npoints in the history, run tests and whatnot. So this would be a UX\nregression for me because I do not want to change commit messages and\ndon't want to be bothered.\n\nWith the introduction of the \"break\" command you can certainly argue\nthat \"edit\" is the wrong command to use in my case. Muscle memory is\nhard to retrain though :)\n\nOne could potentially make the behaviour configurable so that you get to\nchoose how \"edit\" behaves.\n\nPatrick\n"},{"id":"494961","messageId":"233aefd10fbe965c190541d353822fe5@manjaro.org","threadId":"61494","inReplyTo":"ZkcH-LAkLkf_wvfq@tanuki","subject":"Re: [Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-05-17T08:54:06Z","receivedAt":"2024-05-17T08:54:16Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-05-17 09:32, Patrick Steinhardt wrote:\n> On Fri, May 17, 2024 at 12:09:54AM -0700, Junio C Hamano wrote:\n>> Sean Allred writes:\n>> \n>> > Setting aside the obvious reality that an actual change here could have\n>> > pretty serious UX considerations for folks with muscle-memory, what in\n>> > your opinion would be the right thing to do? Why? Are rebase commands\n>> > 'shortcuts' or are they intended to be orthogonal? Do they have designed\n>> > purposes?\n>> >\n>> > I'm wondering if you can tease out what the 'ideal' state looks like to\n>> > you, then you can identify what if anything there is to be done about\n>> > it.\n>> \n>> Oh, it would be very simple.\n>> \n>> If I say \"edit\", whether I made a tree change or not, I want to get\n>> an editor when I said \"rebase --continue\". If I say \"reword\", I\n>> want to get an editor _without_ having a chance to muck with the\n>> tree status. That would be the \"ideal\" behaviour, iow, the \"mental\n>> model\" is just \"edit\" gives the users a chance to edit both trees\n>> (by first giving control back to a shell prompt) and the log message\n>> (by opening the editor upon \"--continue\"), while \"reword\" is only\n>> about the message so does not give shell prompt back to the user\n>> (unless absolutely necessary, that is. If the \"reword\" were to\n>> conflict due to tree changes in earlier steps, it would need to give\n>> control back to a shell prompt to ask the user's help to resolve the\n>> conflict. It is just that when there is no need to edit the tree\n>> otherwise, that is skipped).\n> \n> I quite frequently use \"edit\" just to inspect commits, stop at random\n> points in the history, run tests and whatnot. So this would be a UX\n> regression for me because I do not want to change commit messages and\n> don't want to be bothered.\n> \n> With the introduction of the \"break\" command you can certainly argue\n> that \"edit\" is the wrong command to use in my case. Muscle memory is\n> hard to retrain though :)\n> \n> One could potentially make the behaviour configurable so that you get \n> to\n> choose how \"edit\" behaves.\n\nI agree that it would be best to introduce a new configuration option\nfor this purpose. Making such a change in the behavior of interactive\nrebase permanently would probably result in more than a few raised\neyebrows, while a new configuration option would be a safe choice.\n"},{"id":"494965","messageId":"6620412e-a8ea-40fb-8823-13c4b33e9808@xiplink.com","threadId":"61494","inReplyTo":"xmqqy189o94c.fsf@gitster.g","subject":"Re: [Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2024-05-17T12:42:41Z","receivedAt":"2024-05-17T12:42:44Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nOn 2024-05-16 15:21, Junio C Hamano wrote:\n> What should happen when I turn \"pick\" to \"edit\" in a \"rebase -i\"\n> session, check what got checked out in the working tree, find it\n> satisfactory and decide not to make any change to the files, and say\n> \"rebase --continue\"?\n> \n> The current implementation seems to just move to the next step,\n> without offering a chance to edit the log message. I do not know\n> offhand if this is something we changed recently, or if it has been\n> that way forever.\n\nIt's been this way forever (or close enough; I've been using Git since \n~2010).\n\n> I personally found this a bit unintuitive, because in my metal\n> model, \"reword\" is a mere subset of \"edit\": the latter would give me\n> chances to change both the contents and the log, while the former\n> only would offer me a chance to change the log.\n> \n> But the actual behaviour does not match that mental model. \"edit\"\n> is purely about editing the worktree files, and only if files (hence\n> the tree recorded) are modified, a chance to edit the log is offered\n> to adjust the message to what the new tree brings on top of the\n> parent commit.\n\nMy mental model has always been that \"edit\" means \"amend\" -- when I tell \n\"git rebase\" I want to \"edit\" a commit it (usually) means I intend to \n\"git commit --amend\" it in some fashion, whether that's to update the \ntree the commit changes, or to tweak the message, or both. (Or \nsomething else entirely -- since I'm at the shell prompt, I can do \nanything! The power!)\n\nI like that \"edit\" does not open the editor if I decide not to change \nany files, but does open it if I do change any files (and that \"git \nrebase\" does the amending for me if I just stage the changes and say \n\"git rebase --continue\"). Seeing the editor after I say \"git rebase \n--continue\" is also a good reminder to me that I've changed something in \nthe tree being committed. I've found this helpful if I've been \ndistracted during a rebase session.\n\nIf I *know* that I only want to edit the message, then I say \"reword\".\n\n> Of course, we can work it around with \"git rebase --edit-todo\"\n> before saying \"git rebase --continue\".\n\nOr, more directly, just \"git commit --amend\".\n\n> But the current behaviour\n> somehow feels optimized for a wrong case. Admittedly, it is logical\n> that it does not offer a chance to edit the log message if we did\n> not make any change to the working tree. After all, the reason why\n> it may become necessary to edit the log is because the user made\n> some changes to the tree in the first place. And by not opening the\n> editor, only to close it without making any change, the command is\n> saving the user some keystrokes.\n\nYes, and I've always appreciated this behaviour.\n\n\t\tM.\n\n> But given that saying \"edit\" and not making any changes is a rare\n> case, it feels wrong thing to optimize for.\n> \n> Anyway.\n> \n"},{"id":"494970","messageId":"m0eda0sfz7.fsf@epic96565.epic.com","threadId":"61494","inReplyTo":"233aefd10fbe965c190541d353822fe5@manjaro.org","subject":"Re: [Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Sean Allred","fromEmail":"allred.sean@gmail.com","sentAt":"2024-05-17T13:52:28Z","receivedAt":"2024-05-17T13:52:31Z","isPatch":false,"sender":{"key":"allred.sean@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2082195?v=4"},"body":"\nDragan Simic writes:\n> On 2024-05-17 09:32, Patrick Steinhardt wrote:\n>> I quite frequently use \"edit\" just to inspect commits, stop at\n>> random\n>> points in the history, run tests and whatnot. So this would be a UX\n>> regression for me because I do not want to change commit messages and\n>> don't want to be bothered.\n>> With the introduction of the \"break\" command you can certainly argue\n>> that \"edit\" is the wrong command to use in my case. Muscle memory is\n>> hard to retrain though :)\n>> One could potentially make the behaviour configurable so that you\n>> get to\n>> choose how \"edit\" behaves.\n>\n> I agree that it would be best to introduce a new configuration option\n> for this purpose. Making such a change in the behavior of interactive\n> rebase permanently would probably result in more than a few raised\n> eyebrows, while a new configuration option would be a safe choice.\n\nI would strongly disagree that new configuration would be best here.\ngit-config isn't a silver bullet for finding a 'one size fits all'\nsolution -- on the contrary, it usually only serves to confuse the\ncommunity in situations where a decision should just have been made.\n\nI've thought on this on and off and, were I asked the question 'what\nwould you do if there were no precedent', I'd agree that 'edit'\nshouldn't simply be a shortcut for 'pick' then 'break'. Sequence editors\nare where such shortcuts should be implemented, IMO.\n\nI want to be clear that I'm not saying the behavior *should* change at\nthis point (at least not without the set of other breaking changes\ndiscussed elsewhere in the so-called Git 3.0 thread), but I can see why\n'edit' having the behavior of invoking the editor every time would be\ndesirable -- *because* each command should ideally have one clear job.\n\ngit-rebase(1) does briefly describe these commands, but perhaps not in a\nway that makes the relationship between them as clear as it could be:\n\n By replacing the command \"pick\" with the command \"edit\", you can\n tell git rebase to stop after applying that commit, so that you\n can edit the files and/or the commit message, amend the commit,\n and continue rebasing.\n\n To interrupt the rebase (just like an \"edit\" command would do,\n but without cherry-picking any commit first), use the \"break\"\n command.\n\n If you just want to edit the commit message for a commit, replace\n the command \"pick\" with the command \"reword\".\n\n To drop a commit, replace the command \"pick\" with \"drop\", or just\n delete the matching line.\n\n..\n\nI don't disagree that the behavior of 'edit' could change in a Git 3.0\nand that such would be a positive change, but:\n\n- such would be a breaking change -- I know of several tools that use\n interactive rebase in a scripted/non-interactive fashion\n- introducing configuration to avoid the breaking change would, IMO,\n cause more harm than good. In my mind, it would be no different than\n having opt-in configuration to automatically staged everything when\n running git-commit.\n\n-- \nSean Allred\n"},{"id":"494975","messageId":"xmqqh6ewmpr0.fsf@gitster.g","threadId":"61494","inReplyTo":"ZkcH-LAkLkf_wvfq@tanuki","subject":"Re: [Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-05-17T15:17:55Z","receivedAt":"2024-05-17T15:18:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> I quite frequently use \"edit\" just to inspect commits, stop at random\n> points in the history, run tests and whatnot. So this would be a UX\n> regression for me because I do not want to change commit messages and\n> don't want to be bothered.\n\nI sometimes (ab)use the \"edit\" exactly like that myself, so a\nsimple-minded unconditional change of behaviour would be a UX\nregression to me as well.\n\n> With the introduction of the \"break\" command you can certainly argue\n> that \"edit\" is the wrong command to use in my case. Muscle memory is\n> hard to retrain though :)\n\nYes, with a vim macro or its Emacs equivalent, it should be just as\neasy as doing \"s/^pick /edit /\" to insert \"break\" after every line\nthat begins with \"pick \", but \"just as easy\" is still an unwanted\nforced change to the end-users. If I really wanted to, the right\nand only way out is to introduce a new insn similar to \"edit\" but\nbehaves more like what I said earlier.\n\nThanks.\n\n"},{"id":"494986","messageId":"xmqqo794jro6.fsf@gitster.g","threadId":"61494","inReplyTo":"6620412e-a8ea-40fb-8823-13c4b33e9808@xiplink.com","subject":"Re: [Q] rebase -i: turn \"pick\" to \"edit\", make no change, what should happen?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-05-17T17:04:41Z","receivedAt":"2024-05-17T17:04:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> On 2024-05-16 15:21, Junio C Hamano wrote:\n>> What should happen when I turn \"pick\" to \"edit\" in a \"rebase -i\"\n>> session, check what got checked out in the working tree, find it\n>> satisfactory and decide not to make any change to the files, and say\n>> \"rebase --continue\"?\n>> The current implementation seems to just move to the next step,\n>> without offering a chance to edit the log message. I do not know\n>> offhand if this is something we changed recently, or if it has been\n>> that way forever.\n>\n> It's been this way forever (or close enough; I've been using Git since\n> ~2010).\n\nThanks.\n"}]}