From: John Tapsell Date: Wed, 17 Jun 2009 16:40:06 GMT Subject: Re: git rebase --interactive squash/squish/fold/rollup Message-ID: <43d8ce650906170940m17942793xe0cd88ae372ff8f2@mail.gmail.com> In-Reply-To: <7vvdmurfao.fsf@alter.siamese.dyndns.org> 2009/6/17 Junio C Hamano : > John Tapsell writes: > >>> branch, hack, commit. >>> hack, commit, hack, commit >> >> What if you used  commit --append  instead? >> >> The trouble though of squashing all the commits into one is that it >> makes it impossible to bisect later.  Are you really sure that your >> final commit cannot be broken into small commits?  Ideally each commit >> is small but self contained.  Squashing should be done only to fix >> cases where you introduced a bug then fixed it, or to fix a partial >> implementation etc. > > I think you meant --amend, but it often happens to me that after preparing > a three-patch series: > >        [1/3] Clean up the surrounding code I will touch >        [2/3] Lay the groundwork >        [3/3] Implement a cool new feature > > I find that there are more clean-up that should have been done in [1/3]. > The way "rebase -i" expects me to work is: > >        $ edit ;# more clean-ups >        $ git commit -a -m 'squash to "clean up"' >        $ git rebase -i HEAD~5 > > which will give me > >        pick 1/3 Clean up ... >        pick 2/3 Lay the groundwork >        pick 3/3 Implement >        pick 4/3 squash to "clean up" > > that I'll change to > >        pick 1/3 Clean up ... >        squash 4/3 squash to "clean up" >        pick 2/3 Lay the groundwork >        pick 3/3 Implement Yeah. It would be nice to have a 'crush' or something here. It's similar to the arguments to have a command to just edit the commit message in a single go, rather than the rather long way of using edit.