{"thread":{"id":"54877","subject":"Git Feature Request (Fixdown in interactive rebase)","startedAt":"2020-12-23T23:09:51Z","lastAt":"2021-01-27T08:09:29Z","messageCount":10,"participants":["Mike McLean","brian m. carlson","Junio C Hamano","Johannes Sixt","Johannes Schindelin","Charvi Mendiratta"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"412959","messageId":"CAM0jFOdCD1uEcHaPB_go7aarapEBKx6M4d35zVOP8h9=MuZEmA@mail.gmail.com","threadId":"54877","inReplyTo":"CAM0jFOeCE-iTAMkiGE6m8bVNjJRn-BUmbUAP2ANrj4FbhuQG=g@mail.gmail.com","subject":"Git Feature Request (Fixdown in interactive rebase)","fromName":"Mike McLean","fromEmail":"stixmclean@googlemail.com","sentAt":"2020-12-23T23:08:58Z","receivedAt":"2020-12-23T23:09:51Z","isPatch":false,"sender":{"key":"stixmclean@googlemail.com","avatar":"https://gravatar.com/avatar/429ebb046116546906581c5e40a055b9be286775620cae8af1a399d7a8bea15a?d=mp&s=160"},"body":"I initially raised this as a FR with my git UI of choice, and was told\nthat it was actually something that git itself would need to do ...\nand that the standard way to raise Feature Requests was to email this\nlist.\n\nApologies if that's not actually what I should be doing - please let\nme know if this is not an intended use.\n\n=-=-=-=-=-=-=-=\n\nDuring an interactive rebase, the text file defining the operations\nhas a command option for \"fixup\".\nThis will squash the target commit into the previous commit (listed\nabove it in the file), and automatically use the commit message of the\nprevious commit (thus bypassing the \"choose the commit message\"\ndialog/file).\n\nCan we have a similar convenience-command that squashes, and retains\nthe second commit's message? Purpose is the same as the fixup command\n- saving a bit of time and unnecessary typing during a common\noperation.\n\nAm happy to suggest names and/or shorthand keys for it, if the idea is\nacceptable.\n\nYours,\nBrondahl\n"},{"id":"412960","messageId":"X+PR6yms1G9zVcML@camp.crustytoothpaste.net","threadId":"54877","inReplyTo":"CAM0jFOdCD1uEcHaPB_go7aarapEBKx6M4d35zVOP8h9=MuZEmA@mail.gmail.com","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-12-23T23:25:31Z","receivedAt":"2020-12-23T23:26:49Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-12-23 at 23:08:58, Mike McLean wrote:\n> I initially raised this as a FR with my git UI of choice, and was told\n> that it was actually something that git itself would need to do ...\n> and that the standard way to raise Feature Requests was to email this\n> list.\n\nThis is absolutely the right place.\n\n> During an interactive rebase, the text file defining the operations\n> has a command option for \"fixup\".\n> This will squash the target commit into the previous commit (listed\n> above it in the file), and automatically use the commit message of the\n> previous commit (thus bypassing the \"choose the commit message\"\n> dialog/file).\n> \n> Can we have a similar convenience-command that squashes, and retains\n> the second commit's message? Purpose is the same as the fixup command\n> - saving a bit of time and unnecessary typing during a common\n> operation.\n\nMaybe I'm misunderstanding what you want, but I think the \"squash\"\ncommand does what you want. It does invoke the editor to edit it, which\ntends to be useful when working on projects that use a sign-off, since\notherwise your second commit message would be tacked on after the\nsign-off and other trailers.\n\nIf you really want to avoid the editor prompt, you can run your rebase\nlike so:\n\n GIT_SEQUENCE_EDITOR=\"$(git var GIT_EDITOR)\" GIT_EDITOR=true git rebase -i\n\nwhich will avoid spawning an editor except for the todo list and will\nimplicitly concatenate the two messages. That will also make any\n\"reword\" options a no-op, though.\n\nIf you were looking for an editor command that just concatenates the two\nmessages without an editor prompt, then no, we don't have that, and that\nwould be a new feature. I wouldn't use it because most of my projects\nuse sign-offs, but I'll let other folks weigh in if that's a feature\nthey'd like to see.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"412961","messageId":"CAM0jFOddeArOtbrKVGP0r3Nh=GHPoKqyZ7v6==iFTMpTus4-Fw@mail.gmail.com","threadId":"54877","inReplyTo":"X+PR6yms1G9zVcML@camp.crustytoothpaste.net","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"Mike McLean","fromEmail":"stixmclean@googlemail.com","sentAt":"2020-12-23T23:28:47Z","receivedAt":"2020-12-23T23:29:56Z","isPatch":false,"sender":{"key":"stixmclean@googlemail.com","avatar":"https://gravatar.com/avatar/429ebb046116546906581c5e40a055b9be286775620cae8af1a399d7a8bea15a?d=mp&s=160"},"body":"I think I was unclear :)\nI mean that the new command would take *only* the 2nd commit message.\n(By analogy to `fixup` which takes *only* the 1st commit message)\n\nI agree that `squash` currently gives you the concatenation of both\ncommits (\"all\", if squashing >2 commits)\n\nOn Wed, Dec 23, 2020 at 11:25 PM brian m. carlson\n wrote:\n>\n> On 2020-12-23 at 23:08:58, Mike McLean wrote:\n> > I initially raised this as a FR with my git UI of choice, and was told\n> > that it was actually something that git itself would need to do ...\n> > and that the standard way to raise Feature Requests was to email this\n> > list.\n>\n> This is absolutely the right place.\n>\n> > During an interactive rebase, the text file defining the operations\n> > has a command option for \"fixup\".\n> > This will squash the target commit into the previous commit (listed\n> > above it in the file), and automatically use the commit message of the\n> > previous commit (thus bypassing the \"choose the commit message\"\n> > dialog/file).\n> >\n> > Can we have a similar convenience-command that squashes, and retains\n> > the second commit's message? Purpose is the same as the fixup command\n> > - saving a bit of time and unnecessary typing during a common\n> > operation.\n>\n> Maybe I'm misunderstanding what you want, but I think the \"squash\"\n> command does what you want. It does invoke the editor to edit it, which\n> tends to be useful when working on projects that use a sign-off, since\n> otherwise your second commit message would be tacked on after the\n> sign-off and other trailers.\n>\n> If you really want to avoid the editor prompt, you can run your rebase\n> like so:\n>\n> GIT_SEQUENCE_EDITOR=\"$(git var GIT_EDITOR)\" GIT_EDITOR=true git rebase -i\n>\n> which will avoid spawning an editor except for the todo list and will\n> implicitly concatenate the two messages. That will also make any\n> \"reword\" options a no-op, though.\n>\n> If you were looking for an editor command that just concatenates the two\n> messages without an editor prompt, then no, we don't have that, and that\n> would be a new feature. I wouldn't use it because most of my projects\n> use sign-offs, but I'll let other folks weigh in if that's a feature\n> they'd like to see.\n> --\n> brian m. carlson (he/him or they/them)\n> Houston, Texas, US\n"},{"id":"412965","messageId":"xmqqczz05b4x.fsf@gitster.c.googlers.com","threadId":"54877","inReplyTo":"CAM0jFOdCD1uEcHaPB_go7aarapEBKx6M4d35zVOP8h9=MuZEmA@mail.gmail.com","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-23T23:57:18Z","receivedAt":"2020-12-23T23:59:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike McLean writes:\n\n> Can we have a similar convenience-command that squashes, and retains\n> the second commit's message? Purpose is the same as the fixup command\n> - saving a bit of time and unnecessary typing during a common\n> operation.\n\nWe can view \"fixup\" as a slight variant of \"squash\" that gives us\nthe right tree by applying the change in the second commit while\nreusing the message from the first commit, and the reason why its\nexistence makes sense is because it often happens that users find\nsmall mistakes in the committed content that needs \"fixing up\" but\nthe small mistakes do not change the intent of the original change\nso the message does not need any \"fixing up\".\n\nIt also often happens that users find small mistakes in the log\nmessage text that needs \"fixing up\", but there is no need to change\nthe committed content (iow the recorded tree object), and that is\nwhy \"reword\" is a useful command to have.\n\nYou are bringing up another variant of \"squash\" that gives us the\nright tree by applying the change in the second commit while\ndiscarding the message from the first commit and replacing it with\nthe message from the second commit. Can we justify existence of\nsuch a mode in a similar way (like I showed above to justify why\n\"fixup\" and \"reword\" make sense)? \n\nWhat is the most unclear to me is where the log message in the\nsecond commit comes from. Was it first copied from the first commit\nand then edited? IOW, did the user do something like this?\n\n\t$ work work work\n\t$ git commit -e\n\t... record and explain the work of the first commit\n\t... with sufficient detail\n\t$ work a bit more to fix things\n\t$ git commit -c HEAD\n\t... record and explain the work of both the first and\n\t... the second by copying the existing first commit's log\n\t... and expanding to cover what the user further did\n\nOr did the user do something more like this, in which case the log\nmessage of the second was written pretty much from scratch to cover\nwork done by both commits?\n\n\t$ work work work\n\t$ git commit -m snapshot\n\t... record but give it a meaningless and expendable log\n\t... message\n\t$ work a lot more to advance\n\t$ git commit -e\n\t... record and explain what was done on the branch as\n\t... a whole; the log message of this commit fully describes\n\t... what the both commit did\n\nBoth workflows may benefit from such a feature, but at the same\ntime, it is unclear how realistic they are.\n\nIf two commits did comparable amount of work with similar\ncomplexity, it would be more realistic for them to have their own\nexplanation that is usable as a part of the final, squashed commit,\nand that is why \"squash\" exists. It just is not obvious when the\nnew variant would be useful. Especially if the workflow it expects\nto support is the latter kind I gave (i.e. the user delays writing\nmeaningful log message until the last commit in the series and then\nsquashes everything down to one), it smells good enough to use\n\"squash\" and get rid of a few lines at the beginning. So there must\nbe some realistic workflow that benefits from the new variant, but I\ndo not think of one myself.\n\nWhen such an explanation is given, I may agree that such a mode is a\ngood thing to add, but \"similar to fixup\" does not look like a good\nenough reason.\n\nThanks.\n"},{"id":"412968","messageId":"CAM0jFOfSE3_TQ7WXiR_G6eHOZnr-0ryv=CniXs4sxs1=JnucUg@mail.gmail.com","threadId":"54877","inReplyTo":"xmqqczz05b4x.fsf@gitster.c.googlers.com","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"Mike McLean","fromEmail":"stixmclean@googlemail.com","sentAt":"2020-12-24T00:13:56Z","receivedAt":"2020-12-24T00:14:50Z","isPatch":false,"sender":{"key":"stixmclean@googlemail.com","avatar":"https://gravatar.com/avatar/429ebb046116546906581c5e40a055b9be286775620cae8af1a399d7a8bea15a?d=mp&s=160"},"body":"I agree that \"realism and frequency of use case\" is a critical metric :D\n\nFor me it's very much the 2nd case you described and there are 2\nscenarios that it comes up in most frequently:\n\n1) WIP commits.\nFor whatever reason I want to create a commit even though the work is\nnowhere near ready or functional. It's not that I've done part of the\ntask and there's a separate extra bit pending - I'm just creating a\ntemporary save point.\nMaybe I'm putting work down in the middle due to some external factor.\n(Perhaps a colleague needed some help for something, for which jumping\nover onto their branch was the most useful thing to do. Perhaps a\nblocking bug was just found in our UAT that needs a 2 line fix put in\nright *now*. Whatever... :D)\nOr Maybe I'm part way through some work and want to attempt a\ndifferent approach but I want a \"save point\" if I get part way through\nand decide I was right the first time.\n\nWhatever the case, I've created a WIP commit because I don't want the\nhassle of crafting a good commit message right now. When I come back\nto it, I forget there was a WIP commit, and finish the work and create\na sensible commit message. When reviewing my commit history prior to\nreview, I notice the WIP commit and want to squash it into the final\ncommit.\n\n2) Interactive rebases\nI make heavy use of interactive rebases, in order to make committing\nbe a REALLY low effort task. If I don't have to clean up my commits\nwhen I make them, then I can commit really easily, which means I\ncommit frequently, which is a good thing :D But then I have a messy\ngit history. Especially if I'm juggling a bunch of small fixes at\nonce, and I end up with bits of one fix/refactor in a commit that was\nmostly about another thing.\n\nNot a problem: Interactive rebase to the rescue!\n\nI use `edit` mode to split stuff apart and then squash mode to push\nthe relevant bits back together again.\nBut a downside of this is that frequently I end up with the commit\nwith the good message being *after* the scrappy bit that's just been\nsplit off from another commit.\nSometimes I can just pull that scrappy bit past the main commit and\nthen `fixup` that bit, but often that would cause merge conflicts, so\nit'd be easier to have a fixdown that does exactly what I'm going to\ndo with `squash`.\n\n=-=-=-=-=-=-=-=-=-=-=\n\nI recognise that these might be very niche or non-standard usages, and\nif you don't think there would be much demand for such functionality\nthen I'm fine with that :D\nJust figured I'd throw it in and see whether there was an appetite.\n\nOn Wed, Dec 23, 2020 at 11:57 PM Junio C Hamano wrote:\n>\n> Mike McLean writes:\n>\n> > Can we have a similar convenience-command that squashes, and retains\n> > the second commit's message? Purpose is the same as the fixup command\n> > - saving a bit of time and unnecessary typing during a common\n> > operation.\n>\n> We can view \"fixup\" as a slight variant of \"squash\" that gives us\n> the right tree by applying the change in the second commit while\n> reusing the message from the first commit, and the reason why its\n> existence makes sense is because it often happens that users find\n> small mistakes in the committed content that needs \"fixing up\" but\n> the small mistakes do not change the intent of the original change\n> so the message does not need any \"fixing up\".\n>\n> It also often happens that users find small mistakes in the log\n> message text that needs \"fixing up\", but there is no need to change\n> the committed content (iow the recorded tree object), and that is\n> why \"reword\" is a useful command to have.\n>\n> You are bringing up another variant of \"squash\" that gives us the\n> right tree by applying the change in the second commit while\n> discarding the message from the first commit and replacing it with\n> the message from the second commit. Can we justify existence of\n> such a mode in a similar way (like I showed above to justify why\n> \"fixup\" and \"reword\" make sense)?\n>\n> What is the most unclear to me is where the log message in the\n> second commit comes from. Was it first copied from the first commit\n> and then edited? IOW, did the user do something like this?\n>\n> $ work work work\n> $ git commit -e\n> ... record and explain the work of the first commit\n> ... with sufficient detail\n> $ work a bit more to fix things\n> $ git commit -c HEAD\n> ... record and explain the work of both the first and\n> ... the second by copying the existing first commit's log\n> ... and expanding to cover what the user further did\n>\n> Or did the user do something more like this, in which case the log\n> message of the second was written pretty much from scratch to cover\n> work done by both commits?\n>\n> $ work work work\n> $ git commit -m snapshot\n> ... record but give it a meaningless and expendable log\n> ... message\n> $ work a lot more to advance\n> $ git commit -e\n> ... record and explain what was done on the branch as\n> ... a whole; the log message of this commit fully describes\n> ... what the both commit did\n>\n> Both workflows may benefit from such a feature, but at the same\n> time, it is unclear how realistic they are.\n>\n> If two commits did comparable amount of work with similar\n> complexity, it would be more realistic for them to have their own\n> explanation that is usable as a part of the final, squashed commit,\n> and that is why \"squash\" exists. It just is not obvious when the\n> new variant would be useful. Especially if the workflow it expects\n> to support is the latter kind I gave (i.e. the user delays writing\n> meaningful log message until the last commit in the series and then\n> squashes everything down to one), it smells good enough to use\n> \"squash\" and get rid of a few lines at the beginning. So there must\n> be some realistic workflow that benefits from the new variant, but I\n> do not think of one myself.\n>\n> When such an explanation is given, I may agree that such a mode is a\n> good thing to add, but \"similar to fixup\" does not look like a good\n> enough reason.\n>\n> Thanks.\n"},{"id":"412991","messageId":"ab835195-0c69-830b-c7cb-71d50b4ce4db@kdbg.org","threadId":"54877","inReplyTo":"CAM0jFOfSE3_TQ7WXiR_G6eHOZnr-0ryv=CniXs4sxs1=JnucUg@mail.gmail.com","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2020-12-24T09:16:00Z","receivedAt":"2020-12-24T09:16:49Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 24.12.20 um 01:13 schrieb Mike McLean:\n> I agree that \"realism and frequency of use case\" is a critical metric :D\n> \n> For me it's very much the 2nd case you described and there are 2\n> scenarios that it comes up in most frequently:\n> \n> [...]\n> 2) Interactive rebases\n> I make heavy use of interactive rebases, in order to make committing\n> be a REALLY low effort task. If I don't have to clean up my commits\n> when I make them, then I can commit really easily, which means I\n> commit frequently, which is a good thing :D But then I have a messy\n> git history. Especially if I'm juggling a bunch of small fixes at\n> once, and I end up with bits of one fix/refactor in a commit that was\n> mostly about another thing.\n> \n> Not a problem: Interactive rebase to the rescue!\n> \n> I use `edit` mode to split stuff apart and then squash mode to push\n> the relevant bits back together again.\n> But a downside of this is that frequently I end up with the commit\n> with the good message being *after* the scrappy bit that's just been\n> split off from another commit.\n> Sometimes I can just pull that scrappy bit past the main commit and\n> then `fixup` that bit, but often that would cause merge conflicts, so\n> it'd be easier to have a fixdown that does exactly what I'm going to\n> do with `squash`.\n> \n> =-=-=-=-=-=-=-=-=-=-=\n> \n> I recognise that these might be very niche or non-standard usages, and\n> if you don't think there would be much demand for such functionality\n> then I'm fine with that :D\n\nI would not say that your workflow is exceptional; quite the contrary: I\ndo exactly like you explained. And I guess that many others do as well\n(interactive rebase was invented for uses cases like yours).\n\nI don't mind using 'squash' to consolidate commits where the meat of the\nchange and the commit message is not in the first one.\n\nBut consider a situation like this, which I find myself in regularly:\n\n $ work\n $ git commit -m \"WIP begin feature\"\n $ work -- ah, this can be done independently:\n $ git commit -m \"refactor stuff\"\n $ do the real feature (takes time, many commits)\n # finally:\n $ git commit -m \"the real feature\"\n\nHere I wish that the final commit carries an author date that should be\nafter the \"refactor\" commit to be realistic. But 'squash' takes\nauthorship including the date from the first commit (the \"WIP\" commit in\nthis example). That is where the suggested feature could help. I admit,\nthough, that it's not a huge deal.\n\n-- Hannes\n"},{"id":"413007","messageId":"xmqq8s9m3kx4.fsf@gitster.c.googlers.com","threadId":"54877","inReplyTo":"ab835195-0c69-830b-c7cb-71d50b4ce4db@kdbg.org","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-24T22:21:11Z","receivedAt":"2020-12-24T22:22:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> But consider a situation like this, which I find myself in regularly:\n>\n> $ work\n> $ git commit -m \"WIP begin feature\"\n> $ work -- ah, this can be done independently:\n> $ git commit -m \"refactor stuff\"\n> $ do the real feature (takes time, many commits)\n> # finally:\n> $ git commit -m \"the real feature\"\n>\n> Here I wish that the final commit carries an author date that should be\n> after the \"refactor\" commit to be realistic. But 'squash' takes\n> authorship including the date from the first commit (the \"WIP\" commit in\n> this example). That is where the suggested feature could help. I admit,\n> though, that it's not a huge deal.\n\nYeah, I actually find that an interesting scenario.\n\nIn such a workflow, you'd want to view all the previous steps\nbuilding pieces as preparing for the final step that makes the\ncumulative effort into presentable whole. Whether you want to use\nthe log message only from the last step or want to use the \"squash\"\nto collect pieces from all the WIP commits, you would want the other\naspects of the resulting single commit to be more similar to the\nfinal one rather than the earlier one(s), as if you did something\nlike \"commit --reset-author --amend\" (yes, I am including the case\nwhere the work on the branch was a team effort and the one that\ncollects them into a single resulting commit would become the\n\"corresponding author\").\n\nI wonder if we deliberately designed how each insn you can write in\nthe todo list should come up with the authorship data (i.e. ident\nand timestamp), or if we are just using the natural consequence of\nhow the implementation happens to work? I think it makes sense for\n\"fixup\", as an instruction used to make a small tweak to the bulk of\nwork you've done some time ago, to use the authorship information of\nthe original commit that gets fixed up. I don't know offhand what\nother insns like \"edit\", \"reword\", etc. do, and if there is a room\nto improve them.\n\n"},{"id":"413011","messageId":"7b5ad849-ca6c-a462-fdef-c06f8511d946@kdbg.org","threadId":"54877","inReplyTo":"xmqq8s9m3kx4.fsf@gitster.c.googlers.com","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2020-12-24T22:54:04Z","receivedAt":"2020-12-24T22:55:05Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 24.12.20 um 23:21 schrieb Junio C Hamano:\n> I wonder if we deliberately designed how each insn you can write in\n> the todo list should come up with the authorship data (i.e. ident\n> and timestamp), or if we are just using the natural consequence of\n> how the implementation happens to work? I think it makes sense for\n> \"fixup\", as an instruction used to make a small tweak to the bulk of\n> work you've done some time ago, to use the authorship information of\n> the original commit that gets fixed up. I don't know offhand what\n> other insns like \"edit\", \"reword\", etc. do, and if there is a room\n> to improve them.\n\nFor 'squash' it was a deliberate decision to keep authorship of the\nfirst commit, see 81ab1cb43a87. Initially, 'edit' changed authorship\nincluding the date to the current author and date; that was changed to\npreserve them, but I cannot find the responsible commit.\n\n-- Hannes\n"},{"id":"413618","messageId":"nycvar.QRO.7.76.6.2101062336350.2213@tvgsbejvaqbjf.bet","threadId":"54877","inReplyTo":"7b5ad849-ca6c-a462-fdef-c06f8511d946@kdbg.org","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-01-06T22:40:55Z","receivedAt":"2021-01-06T22:42:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Dec 2020, Johannes Sixt wrote:\n\n> Am 24.12.20 um 23:21 schrieb Junio C Hamano:\n> > I wonder if we deliberately designed how each insn you can write in\n> > the todo list should come up with the authorship data (i.e. ident\n> > and timestamp), or if we are just using the natural consequence of\n> > how the implementation happens to work? I think it makes sense for\n> > \"fixup\", as an instruction used to make a small tweak to the bulk of\n> > work you've done some time ago, to use the authorship information of\n> > the original commit that gets fixed up. I don't know offhand what\n> > other insns like \"edit\", \"reword\", etc. do, and if there is a room\n> > to improve them.\n>\n> For 'squash' it was a deliberate decision to keep authorship of the\n> first commit, see 81ab1cb43a87. Initially, 'edit' changed authorship\n> including the date to the current author and date; that was changed to\n> preserve them, but I cannot find the responsible commit.\n\nNote that a new verb is not even necessary, thanks to the `exec` verb:\nSomething like this:\n\n\tpick \n\tsquash \n\texec git commit --amend -C \n\nAs to the implementation of a hypothetical `fixdown`? It would be a bit\nhairy, I think: right now, we rely on the fact that we can find the target\nof every fixup!/squash! in the already-parsed todo list. If we do not find\nit there, the fixup!/squash! simply won't be auto-squashed. The desired\nfeature, however, would have to look in the opposite direction. I'd rather\navoid that complexity.\n\nCiao,\nJohannes\n"},{"id":"415402","messageId":"CAPSFM5d79AEx478twqrLpUuhq1+mF_bvOsfyvRuQVgQO167DrA@mail.gmail.com","threadId":"54877","inReplyTo":"CAM0jFOdCD1uEcHaPB_go7aarapEBKx6M4d35zVOP8h9=MuZEmA@mail.gmail.com","subject":"Re: Git Feature Request (Fixdown in interactive rebase)","fromName":"Charvi Mendiratta","fromEmail":"charvi077@gmail.com","sentAt":"2021-01-27T07:55:14Z","receivedAt":"2021-01-27T08:09:29Z","isPatch":false,"sender":{"key":"charvi077@gmail.com","avatar":"https://avatars.githubusercontent.com/u/32788121?v=4"},"body":"Hi,\n\nOn Thu, 24 Dec 2020 at 04:42, Mike McLean wrote:\n[...]\n> =-=-=-=-=-=-=-=\n>\n> During an interactive rebase, the text file defining the operations\n> has a command option for \"fixup\".\n> This will squash the target commit into the previous commit (listed\n> above it in the file), and automatically use the commit message of the\n> previous commit (thus bypassing the \"choose the commit message\"\n> dialog/file).\n>\n> Can we have a similar convenience-command that squashes, and retains\n> the second commit's message? Purpose is the same as the fixup command\n> - saving a bit of time and unnecessary typing during a common\n> operation.\n>\n\nIt seems that this FR is addressed by the patches as here[1], which are\nunder review. It adds the options to fixup command i.e fixup [-C|-c] in the\ninteractive rebase that gives the flexibility to select or edit the\ncommit message\nwhile fixing up the commit using fixup command. So, changing `pick` command\nto `fixup -C` will fixup the content and replace the previous commit\nmessage with\nthe second commit message(ie. the fixup commit message).\n\nThanks and Regards,\nCharvi\n\n[1] https://lore.kernel.org/git/20210124170405.30583-1-charvi077@gmail.com/\n"}]}