{"thread":{"id":"30518","subject":"git rebase -f --autosquash","startedAt":"2012-05-12T10:38:42Z","lastAt":"2012-06-04T20:05:35Z","messageCount":8,"participants":["Andy Kitchen","Carlos Martín Nieto","Junio C Hamano","Vincent van Ravesteijn","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"191441","messageId":"D7BE2BACB49749DB9FC37D4ACCCD008B@gmail.com","threadId":"30518","inReplyTo":null,"subject":"git rebase -f --autosquash","fromName":"Andy Kitchen","fromEmail":"kitchen.andy@gmail.com","sentAt":"2012-05-12T10:38:42Z","receivedAt":"2012-05-12T10:38:42Z","isPatch":false,"sender":{"key":"kitchen.andy@gmail.com","avatar":null},"body":"Hi All, \n\nI commonly use:\n\ngit commit --fixup <commit>\n\nto preen commits before pushing them. I can run\n\ngit rebase -i --autosquash HEAD@{upstream}\n\nto apply these fixes, however, autosquash only\napplies to interactive rebases.\n\nBecause I am sure that my fixes are applicable,\nI would like to be able to non-interactively autosquash, possibly\nlike so:\n\ngit rebase -f --autosquash HEAD@{upstream}\n\n\nWould anyone else find this feature useful?\n\n\nKind Regards\n\nAK\n"},{"id":"191444","messageId":"1336820755.3002.11.camel@centaur.lab.cmartin.tk","threadId":"30518","inReplyTo":"D7BE2BACB49749DB9FC37D4ACCCD008B@gmail.com","subject":"Re: git rebase -f --autosquash","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-05-12T11:05:55Z","receivedAt":"2012-05-12T11:05:55Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Sat, 2012-05-12 at 20:38 +1000, Andy Kitchen wrote:\n> Hi All, \n> \n> I commonly use:\n> \n> git commit --fixup <commit>\n> \n> to preen commits before pushing them. I can run\n> \n> git rebase -i --autosquash HEAD@{upstream}\n> \n> to apply these fixes, however, autosquash only\n> applies to interactive rebases.\n> \n> Because I am sure that my fixes are applicable,\n> I would like to be able to non-interactively autosquash, possibly\n> like so:\n> \n> git rebase -f --autosquash HEAD@{upstream}\n> \n> \n> Would anyone else find this feature useful?\n\nIf you're confident that an autosquash would produce the right\ninstructions, you can skip the editor phase by setting the EDITOR\nenvironment variable to something that won't spawn an editor. Popular\nvariants are 'cat' and ':'. I prefer 'cat' because then I can see the\ninstruction set in the terminal and verify it's the correct one. You can\nalso set the rebase.autosquash config variable and then you just have to\ntype\n\n    EDITOR=cat git rebase -i @{u}\n\nor\n\n    EDITOR=: git rebase -i @{u}\n\nand maybe set an alias (I have a 'riu' alias for 'rebase -i @{u}').\n\nI'm not saying an extra option wouldn't be useful, but there's already\nways of making git not spawn a text editor which works for all commands,\nand you can even make an alias that will do precisely that.\n\n   cmn\n"},{"id":"191501","messageId":"7vipfyiuv6.fsf@alter.siamese.dyndns.org","threadId":"30518","inReplyTo":"1336820755.3002.11.camel@centaur.lab.cmartin.tk","subject":"Re: git rebase -f --autosquash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-14T16:35:09Z","receivedAt":"2012-05-14T16:35:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n>     EDITOR=: git rebase -i @{u}\n>\n> and maybe set an alias (I have a 'riu' alias for 'rebase -i @{u}').\n>\n> I'm not saying an extra option wouldn't be useful, but there's already\n> ways of making git not spawn a text editor which works for all commands,\n> and you can even make an alias that will do precisely that.\n\nGiven \"EDITOR=: git commit args...\" and \"EDITOR=: git merge args...\" are\nequivalent to giving \"--no-edit\" option to these commands, I would imagine\n\"git rebase opts... --no-editor args...\" would not be such a stretch.\n"},{"id":"192224","messageId":"33DF11B90FEF4CB6B4103BE0AAF9B256@gmail.com","threadId":"30518","inReplyTo":"7vipfyiuv6.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase -f --autosquash","fromName":"Andy Kitchen","fromEmail":"kitchen.andy@gmail.com","sentAt":"2012-05-26T07:30:21Z","receivedAt":"2012-05-26T07:30:21Z","isPatch":false,"sender":{"key":"kitchen.andy@gmail.com","avatar":null},"body":"On Tuesday, 15 May 2012 at 2:35 AM, Junio C Hamano wrote:\n> Given \"EDITOR=: git commit args...\" and \"EDITOR=: git merge args...\" are\n> equivalent to giving \"--no-edit\" option to these commands, I would imagine\n> \"git rebase opts... --no-editor args...\" would not be such a stretch.\n\nI agree. However, I think it would be more intuitive to make --autosquash\nwork with -f or even just on its own in non-interactive mode.\nIt definitely makes sense practically and semantically to autosquash\nnon-interactively. Otherwise one needs to activate interactive mode\nand effectively disable it in the same command which is a bit esoteric.\n\nI am of the opinion that autosquashing is such a useful feature,\nit's even worth having a separate command:\n\n$ git fix\n\nFor generally rebuilding commits based on directives\nplaced in commit messages. Especially because it integrates\nnicely with `git commit --fixup' as a kind of super amend. While\nthis can be easily added with a bit of customisation, I think\nthat it is generally applicable and useful enough to warrant being\na default part of git.\n\nIn summary, I propose:\n\n1a)\n\n$ git rebase -f --autosquash <base>\nis made to be effectively equivalent to:\n$ EDITOR=: git rebase -i --autosquash <base>\n\n1b)\n\n$ git rebase --autosquash <base>\n(i.e. -f is implicit) is made to be effectively equivalent to:\n$ EDITOR=: git rebase -i --autosquash <base>\n\n\n\n3) A new command is created, for example one of:\n\n$ git fix\n$ git squash\n$ git autosquash\n\nFor preening commits before pushing them upstream.\n\nThe default base for these operations would be HEAD@{upstream}\n\nA config option could also be added to warn the user before pushing\ncommits with messages of the form /^fixup!/ etc.\n\nIt could also be less ad-hoc in its operation than --autosquash\ncurrently is. For example, `git commit --fixup' could note the intended\ntarget for the fix allowing `git fix' to operate correctly even when two\ncommits share the same message.\n\n\n\n\nOf course as with any polite feature request, I am happy to write the\nappropriate code, however not being familiar with the git code-base,\nI would require some guidance.\n\n\nThank you for your time, suggestions welcomed\n\nAK\n"},{"id":"192241","messageId":"4FC0D246.2010701@lyx.org","threadId":"30518","inReplyTo":"33DF11B90FEF4CB6B4103BE0AAF9B256@gmail.com","subject":"Re: git rebase -f --autosquash","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2012-05-26T12:53:26Z","receivedAt":"2012-05-26T12:53:26Z","isPatch":false,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"Op 26-5-2012 9:30, Andy Kitchen schreef:\n> On Tuesday, 15 May 2012 at 2:35 AM, Junio C Hamano wrote:\n>> Given \"EDITOR=: git commit args...\" and \"EDITOR=: git merge args...\" are\n>> equivalent to giving \"--no-edit\" option to these commands, I would imagine\n>> \"git rebase opts... --no-editor args...\" would not be such a stretch.\n> I agree. However, I think it would be more intuitive to make --autosquash\n> work with -f or even just on its own in non-interactive mode.\n> It definitely makes sense practically and semantically to autosquash\n> non-interactively. Otherwise one needs to activate interactive mode\n> and effectively disable it in the same command which is a bit esoteric.\n> ...\n> In summary, I propose:\n>\n> 1a)\n>\n> $ git rebase -f --autosquash<base>\n> is made to be effectively equivalent to:\n> $ EDITOR=: git rebase -i --autosquash<base>\n>\n\nI think the following one-line patch will effectively do what you want.\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 24a2840..c4ffdcd 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -228,8 +228,9 @@ do\n      -p)\n          preserve_merges=t\n          test -z \"$interactive_rebase\" && interactive_rebase=implied\n          ;;\n      --autosquash)\n          autosquash=t\n+        test -z \"$interactive_rebase\" && interactive_rebase=implied\n          ;;\n      --no-autosquash)\n\n\nVincent\n"},{"id":"192259","messageId":"7vobpap1gb.fsf@alter.siamese.dyndns.org","threadId":"30518","inReplyTo":"33DF11B90FEF4CB6B4103BE0AAF9B256@gmail.com","subject":"Re: git rebase -f --autosquash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-27T06:44:52Z","receivedAt":"2012-05-27T06:44:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Kitchen <kitchen.andy@gmail.com> writes:\n\n> 1a)\n>\n> $ git rebase -f --autosquash <base>\n> is made to be effectively equivalent to:\n> $ EDITOR=: git rebase -i --autosquash <base>\n\nI am not sure how you do the above without breaking the existing users and\nother people's use cases, given that giving --force option to rebase has\ntotally different meaning from the above (i.e. \"do not refuse to rebase\neven though the current branch is up to date with respect to <base>\").\nSuch an option overloading, especially for an option \"force\", feels adding\nconfusion without much merit---it is unclear what kind of \"forcing\" is it\ncalling for.\n\n> 1b)\n>\n> $ git rebase --autosquash <base>\n> (i.e. -f is implicit) is made to be effectively equivalent to:\n> $ EDITOR=: git rebase -i --autosquash <base>\n\nI do not think this would work.  \n\nThe --autosquash option is merely a way to help reordering by moving the\n\"fixup!\" commits in the history around without manual action You may have\ncommits created with \"fix\" but _other_ commits in the history that you\nwant to manually reorder in the insn sheet.\n\n> 3) A new command is created, for example one of:\n>\n> $ git fix\n> $ git squash\n> $ git autosquash\n\nAll of these names are so broad and generic---I am not sure if any of them\nwill \"click\" with your single narrow use case, which as far as I can see\nis \"I want rebase with --autosquash but I am not going to do any other\nediting.\"  None of the above three words hints the new command is about\nrebasing.\n\nEven though I find the \"I want rebase with --autosquash but I am not going\nto do any other editing.\" is a workflow element that often appears in the\nreal life, I do not think it deserves its own command that is separate\nfrom \"rebase\".  It is merely a slightly different way to drive \"rebase\",\nafter all.\n\nAnd that \"I want rebase with --autosquash but I am not going to do any\nother editing\" is where my suggestion to use \"--no-edit\" comes from.\n"},{"id":"192839","messageId":"CABURp0p+NbYbiEO3n1iwP4jH63CjqvE6zhk6pHFjGU7+N0=vXA@mail.gmail.com","threadId":"30518","inReplyTo":"7vobpap1gb.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase -f --autosquash","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-06-04T19:44:09Z","receivedAt":"2012-06-04T19:44:09Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Sun, May 27, 2012 at 2:44 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Andy Kitchen <kitchen.andy@gmail.com> writes:\n>\n>> 1a)\n>>\n>> $ git rebase -f --autosquash <base>\n>> is made to be effectively equivalent to:\n>> $ EDITOR=: git rebase -i --autosquash <base>\n>\n> I am not sure how you do the above without breaking the existing users and\n> other people's use cases, given that giving --force option to rebase has\n> totally different meaning from the above (i.e. \"do not refuse to rebase\n> even though the current branch is up to date with respect to <base>\").\n> Such an option overloading, especially for an option \"force\", feels adding\n> confusion without much merit---it is unclear what kind of \"forcing\" is it\n> calling for.\n>\n>> 1b)\n>>\n>> $ git rebase --autosquash <base>\n>> (i.e. -f is implicit) is made to be effectively equivalent to:\n>> $ EDITOR=: git rebase -i --autosquash <base>\n>\n> I do not think this would work.\n>\n> The --autosquash option is merely a way to help reordering by moving the\n> \"fixup!\" commits in the history around without manual action You may have\n> commits created with \"fix\" but _other_ commits in the history that you\n> want to manually reorder in the insn sheet.\n>\n>> 3) A new command is created, for example one of:\n>>\n>> $ git fix\n>> $ git squash\n>> $ git autosquash\n>\n> All of these names are so broad and generic---I am not sure if any of them\n> will \"click\" with your single narrow use case, which as far as I can see\n> is \"I want rebase with --autosquash but I am not going to do any other\n> editing.\"  None of the above three words hints the new command is about\n> rebasing.\n>\n> Even though I find the \"I want rebase with --autosquash but I am not going\n> to do any other editing.\" is a workflow element that often appears in the\n> real life, I do not think it deserves its own command that is separate\n> from \"rebase\".  It is merely a slightly different way to drive \"rebase\",\n> after all.\n>\n> And that \"I want rebase with --autosquash but I am not going to do any\n> other editing\" is where my suggestion to use \"--no-edit\" comes from.\n\nYour suggestion is not that he use \"rebase --autosquash --no-edit\" but\nthat he use \"rebase --autosquash --interactive --no-edit\".  The last\ntwo options appear to be opposites from the outsider's perspective and\nwould seem to be superfluous.  I understand from the code perspective\nthat \"rebase\" and \"rebase --interactive\" are in separate\nimplementations; but from this user's perspective, they are the same\nwith one distinction; the former performs an automatic sequence of\ncommit actions, while the latter shows the sequence first and allows\nme to edit it.  So the command \"git rebase --interactive --no-edit\"\nreads to me like \"git rebase --ask-me-how --noask-me-how\", which is\nnonsensical, at best.\n\nThe only reason Andy would have to add --no-edit to his command is\nbecause the --autosquash option is, inexplicably, only valid in\n--interactive mode.  This seems pointless from this user's\nperspective.  Why does the --autosquash option also need the\n\"--ask-me-how\" option?  If I don't need the --ask-me-how action, I\nshould simply leave it off.  I should not need to also add\n\"--no-ask-me-how\".\n\nThat would look nonsensical.\n\nMaybe it seems explicable to you because \"squash\" is a todo-list\ncommand which is only valid in --interactive.  But this, too, is a\ndetail best left buried in the implementation and not exposed to the\nCLI, imho.\n\n>> 1b)\n>>\n>> $ git rebase --autosquash <base>\n>> (i.e. -f is implicit) is made to be effectively equivalent to:\n>> $ EDITOR=: git rebase -i --autosquash <base>\n\nThis would be my preference, except that it is the \"--interactive\n--no-edit\" which is made implicit when --autosquash is used without\n\"--interactive\".  The fact that these two options are implicit should\nbe hidden from the user and not required of him.  That both are\nrequired seems to me to be an embarrassing, historical implementation\ndetail.\n\nPhil\n"},{"id":"192841","messageId":"7vlik2sv00.fsf@alter.siamese.dyndns.org","threadId":"30518","inReplyTo":"CABURp0p+NbYbiEO3n1iwP4jH63CjqvE6zhk6pHFjGU7+N0=vXA@mail.gmail.com","subject":"Re: git rebase -f --autosquash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-04T20:05:35Z","receivedAt":"2012-06-04T20:05:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord <phil.hord@gmail.com> writes:\n\n> ...  That both are\n> required seems to me to be an embarrassing, historical implementation\n> detail.\n\nI do not know if we are discussing the same thing.\n\nThere is nothing historical in that \"--interactive\" is the word used\nto tell the command that the user wants to replay commits in an\norder that is different from the order they were found in the\noriginal commit DAG.  If you want to tweak the order, you use\n\"interactive\". If you don't, you don't.\n\nThere indeed is implementation detail to worry about. The \"-p\" mode\nthat is *not* about letting the user modify the order of replayed\ncommits internally does use the same machinery as interactive, but\nthat is hidden from the end user (the \"implied\" value in\n$interactive_rebase in git-rebase.sh makes this difference).\n\nBut this case is not about replaying the commit without reordering.\n\nIf you are proposing to rename \"--interactive\" to \"--reorder\" or\nsomething, with a solid migration plan to keep the current users\nhappy, and possibly are proposing to add non-interactive autosquash\nimplementation outside git-rebase--interactive.sh, the issue would\nentirely be different, but I somehow do not sense that is the\ndirection in which you are trying to go.\n"}]}