{"thread":{"id":"35506","subject":"A couple of rebase --autosquash proposals","startedAt":"2013-12-09T02:23:00Z","lastAt":"2013-12-09T23:20:30Z","messageCount":7,"participants":["Brett Randall","Johannes Sixt","Chris Packham","Philippe Vaucher","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"231777","messageId":"CALeEUB4mTpd9tHJCC9Ffrfe6L=m0+gaDsXYSFGaO_tMcxCX_nA@mail.gmail.com","threadId":"35506","inReplyTo":null,"subject":"A couple of rebase --autosquash proposals","fromName":"Brett Randall","fromEmail":"javabrett@gmail.com","sentAt":"2013-12-09T02:23:00Z","receivedAt":"2013-12-09T02:23:00Z","isPatch":false,"sender":{"key":"javabrett@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1103477?v=4"},"body":"Hi,\n\nI am using Git 1.8.4.3 compiled by me on OEL6.  I'd like to be able to\nuse rebase --autosquash like this:\n\n======================\n# git log\n\ncommit b94f970cd869dfbf5254b19867fa7200df732d4f\nAuthor: Me <me@me.com>\nDate:   Mon Dec 9 17:02:32 2013 -0800\n\n    fixup!\n    This is a second fixup.\n\ncommit 64e516c8b26b7e0531a1e8b2fc8dfa21de259b85\nAuthor: Me <me@me.com>\nDate:   Sun Dec 8 17:02:32 2013 -0800\n\n    fixup!\n    This is a meaningful commit-log message, on a new line, that will\nbe discarded later during rebase --autosquash.\n\ncommit f21cd48d5eeac92130dc0617252c6ee6989c0252\nAuthor: Me <me@me.com>\nDate:   Tue Dec 3 21:47:52 2013 -0800\n\n    This is the commit that will be fixed-up.\n\ncommit 259c0eb41ef16ac94868ee3c9253ba938ed24c9f\nAuthor: Me <me@me.com>\nDate:   Mon Dec 2 21:47:52 2013 -0800\n\n    This commit is origin/master.\n======================\n\nthen\n\n# git rebase -i --autosquash 259c0eb41ef16ac94868ee3c9253ba938ed24c9f\n\nThe differences here are:\n\n* fixup! or squash! on it's own would default to fixing-up the\nprevious commit (or result of previous step of rebase if that was a\nsquash/fixup).  Interestingly using HEAD~1 or HEAD^1 works, but it\nonly works for a single fixup/squash.  Is there another treeish that\nwould work?\n* Allow real commit-log text, perhaps only on lines other than the\nfirst line (the one containing the fixup).\n\nThe motivations are:\n\n* I can default a fixup to apply to the previous commit (a common\nwish) without explicitly stating it's treeish or commit-message.\n* I can easily apply multiple fixups.\n* I can retain a meaningful WIP commit-log prior to the rebase - I can\nstill see what each commit does, without needing to forgo the future\nautosquash capability - just put the !fixup or !squash on the first\nline on its own, and put the real changes on line 2 and onwards.  In\nthe case of squash! instead of fixup!, this means I could retain some\nvaluable text to be squashed into the original commit.\n\nThoughts on these two ideas?\n\nThanks\nBrett\n"},{"id":"231780","messageId":"52A56887.4070909@viscovery.net","threadId":"35506","inReplyTo":"CALeEUB4mTpd9tHJCC9Ffrfe6L=m0+gaDsXYSFGaO_tMcxCX_nA@mail.gmail.com","subject":"Re: A couple of rebase --autosquash proposals","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-12-09T06:51:51Z","receivedAt":"2013-12-09T06:51:51Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 12/9/2013 3:23, schrieb Brett Randall:\n> * fixup! or squash! on it's own would default to fixing-up the\n> previous commit (or result of previous step of rebase if that was a\n> squash/fixup).\n\nWhy would you want that? To fixup the previous commit, just use 'git\ncommit --amend'. What am I missing?\n\n-- Hannes\n"},{"id":"231781","messageId":"52A58CBB.6040809@gmail.com","threadId":"35506","inReplyTo":"52A56887.4070909@viscovery.net","subject":"Re: A couple of rebase --autosquash proposals","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-12-09T09:26:19Z","receivedAt":"2013-12-09T09:26:19Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 09/12/13 19:51, Johannes Sixt wrote:\n> Am 12/9/2013 3:23, schrieb Brett Randall:\n>> * fixup! or squash! on it's own would default to fixing-up the\n>> previous commit (or result of previous step of rebase if that was a\n>> squash/fixup).\n> \n> Why would you want that? To fixup the previous commit, just use 'git\n> commit --amend'. What am I missing?\n\nIn the past I've used this kind of approach when doing merging/porting\nwork with 3rd party code (or just large integrations). The first (and\neventually final) commit introduces the new code. The subsequent fixups\naddress build issues which are either errors in the 3rd party code\n(which I will want to submit bug reports for later and carry in my tree\nas real commits) or errors in my merging (which I want to squash into\nthe merge commit). When faced with a screen full of compilation errors\nI'm not sure which of these 2 categories are applicable at the time so I\ntend to have lots of little fixups that I need to juggle around with git\nrebase once I've got the code compiling and passing some tests.\n\nAll that being said I think allowing multiple \"fixup!\\n\" stack up on\neach other might be a bit dangerous. There are cases where\nfixup!-fixup!-real might be useful but those would be hard to\ndistinguish those from cases where someone absent mindedly forgot to put\nsomething after \"fixup!\".\n"},{"id":"231782","messageId":"CAGK7Mr75jPCWWRDE9ohLXaxk-JuRosf8960KfJ0HknaAVq-qXg@mail.gmail.com","threadId":"35506","inReplyTo":"52A58CBB.6040809@gmail.com","subject":"Re: A couple of rebase --autosquash proposals","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2013-12-09T09:39:12Z","receivedAt":"2013-12-09T09:39:12Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> >> * fixup! or squash! on it's own would default to fixing-up the\n> >> previous commit (or result of previous step of rebase if that was a\n> >> squash/fixup).\n> >\n> > Why would you want that? To fixup the previous commit, just use 'git\n> > commit --amend'. What am I missing?\n>\n> In the past I've used this kind of approach when doing merging/porting\n> work with 3rd party code (or just large integrations). The first (and\n> eventually final) commit introduces the new code. The subsequent fixups\n> address build issues which are either errors in the 3rd party code\n> (which I will want to submit bug reports for later and carry in my tree\n> as real commits) or errors in my merging (which I want to squash into\n> the merge commit). When faced with a screen full of compilation errors\n> I'm not sure which of these 2 categories are applicable at the time so I\n> tend to have lots of little fixups that I need to juggle around with git\n> rebase once I've got the code compiling and passing some tests.\n>\n> All that being said I think allowing multiple \"fixup!\\n\" stack up on\n> each other might be a bit dangerous. There are cases where\n> fixup!-fixup!-real might be useful but those would be hard to\n> distinguish those from cases where someone absent mindedly forgot to put\n> something after \"fixup!\".\n\n\nYou guys probably already know about it, but there is `git commit\n--fixup SHA1` to create !fixup commits intended for a particular\ncommit. I think using this feature solves all the problem the OP has?\n\nPhilippe\n"},{"id":"231783","messageId":"CALeEUB5kaJ0j2qqzDN4ZcZbQ1W3Zttvmuqr73Jv+i79FM=b4eg@mail.gmail.com","threadId":"35506","inReplyTo":"52A58CBB.6040809@gmail.com","subject":"Re: A couple of rebase --autosquash proposals","fromName":"Brett Randall","fromEmail":"javabrett@gmail.com","sentAt":"2013-12-09T09:52:21Z","receivedAt":"2013-12-09T09:52:21Z","isPatch":false,"sender":{"key":"javabrett@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1103477?v=4"},"body":"This aims to support code-review workflows of teams that prefer rebase\nover merge, when committing a new peer-reviewed feature.\n\n* Developer starts with commit OM, commits A.\n* During testing, the developer may make further changes, either\nthrough --amend or new commits, but either way, all work is rebased to\na single new commit for review, OM -> A' .\n* A' is pushed as a new branch to origin for team review.  The review\nsystem facilitates the review of the change, and review comments are\nmade.\n* The developer responds to the review comments by making changes in\ncommits B and C, and pushes OM -> A' -> B -> C.  Reviewers can\nunderstand the feedback that has been addressed in the changes with\nthrough the commit-log in B and C.\n* Code passes review.  Because the team prefers rebased commits, A'..C\nis rebased onto the current OM (which may now be OM+10) and committed.\n\nIf the commit-log entries for B and C allow simultaneous\nfixup!/squash! syntax together with and free-text log-text, they can\nserve both purposes: 1) they communicate that the change is a\nfeedback-generated fix (rather than a new feature), and describe which\nparts of the feedback each commit addresses, and 2) they pre-empt and\nsupport the eventual rebase-before-origin-push, through --autosquash\nannotation.\n\nBrett\n\nOn 9 December 2013 20:26, Chris Packham <judge.packham@gmail.com> wrote:\n> On 09/12/13 19:51, Johannes Sixt wrote:\n>> Am 12/9/2013 3:23, schrieb Brett Randall:\n>>> * fixup! or squash! on it's own would default to fixing-up the\n>>> previous commit (or result of previous step of rebase if that was a\n>>> squash/fixup).\n>>\n>> Why would you want that? To fixup the previous commit, just use 'git\n>> commit --amend'. What am I missing?\n>\n> In the past I've used this kind of approach when doing merging/porting\n> work with 3rd party code (or just large integrations). The first (and\n> eventually final) commit introduces the new code. The subsequent fixups\n> address build issues which are either errors in the 3rd party code\n> (which I will want to submit bug reports for later and carry in my tree\n> as real commits) or errors in my merging (which I want to squash into\n> the merge commit). When faced with a screen full of compilation errors\n> I'm not sure which of these 2 categories are applicable at the time so I\n> tend to have lots of little fixups that I need to juggle around with git\n> rebase once I've got the code compiling and passing some tests.\n>\n> All that being said I think allowing multiple \"fixup!\\n\" stack up on\n> each other might be a bit dangerous. There are cases where\n> fixup!-fixup!-real might be useful but those would be hard to\n> distinguish those from cases where someone absent mindedly forgot to put\n> something after \"fixup!\".\n"},{"id":"231806","messageId":"xmqq1u1lzshd.fsf@gitster.dls.corp.google.com","threadId":"35506","inReplyTo":"52A56887.4070909@viscovery.net","subject":"Re: A couple of rebase --autosquash proposals","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-09T20:20:30Z","receivedAt":"2013-12-09T20:20:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> Am 12/9/2013 3:23, schrieb Brett Randall:\n>> * fixup! or squash! on it's own would default to fixing-up the\n>> previous commit (or result of previous step of rebase if that was a\n>> squash/fixup).\n>\n> Why would you want that? To fixup the previous commit, just use 'git\n> commit --amend'. What am I missing?\n\nWhen you are not absolutely sure if the amend is a good thing to do.\n\nThen\n\n\twork work work\n        git commit --fixup HEAD\n\twork work work\n        git commit --fixup HEAD^\n\twork work work\n        git commit --fixup HEAD^^\n\t...\n\tgit rebase --autosquash -i ...\n\nmay become a good way to polish a single commit.\n"},{"id":"231839","messageId":"CALeEUB7ztc0Cfz0J2MJp0HiiDNY1y98AarGeSGKKCtdp_bjekQ@mail.gmail.com","threadId":"35506","inReplyTo":"xmqq1u1lzshd.fsf@gitster.dls.corp.google.com","subject":"Re: A couple of rebase --autosquash proposals","fromName":"Brett Randall","fromEmail":"javabrett@gmail.com","sentAt":"2013-12-09T23:20:30Z","receivedAt":"2013-12-09T23:20:30Z","isPatch":false,"sender":{"key":"javabrett@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1103477?v=4"},"body":"I had not previously noticed commit --fixup, so that is something\nuseful I have learned from this thread, thanks.\n\nThe workflow here can be summarized as \"I have an initial commit and\nsubsequent, review-generated commits, that I'd like to share on a\nreview-branch with proper commit-log comments, but also pre-marked for\nfuture --autosquash\".  So when the review is completed, I can auto\nsquash/fixup all the review-generated commits and rebase onto\norigin/master at the same time.  I find this more appealing than\ncontinually pushing rebased branches to colleagues, as the history is\nlost and it is hard to review incremental changes.\n\nI can live with it as it is: I just use rebase -i and change all\nreview-generated commits pick -> r as if autosquash didn't exist.\nIt's just that when I first tried-out fixup!, I mistakenly thought\nthat I could use the first line as the special syntax, and use\nfollowing-lines as annotation - which is not the case, but I thought\nit might be worth suggesting here.\n\nBrett\n\nOn 10 December 2013 07:20, Junio C Hamano <gitster@pobox.com> wrote:\n> Johannes Sixt <j.sixt@viscovery.net> writes:\n>\n>> Am 12/9/2013 3:23, schrieb Brett Randall:\n>>> * fixup! or squash! on it's own would default to fixing-up the\n>>> previous commit (or result of previous step of rebase if that was a\n>>> squash/fixup).\n>>\n>> Why would you want that? To fixup the previous commit, just use 'git\n>> commit --amend'. What am I missing?\n>\n> When you are not absolutely sure if the amend is a good thing to do.\n>\n> Then\n>\n>         work work work\n>         git commit --fixup HEAD\n>         work work work\n>         git commit --fixup HEAD^\n>         work work work\n>         git commit --fixup HEAD^^\n>         ...\n>         git rebase --autosquash -i ...\n>\n> may become a good way to polish a single commit.\n"}]}