Re: git rebase --interactive squash/squish/fold/rollup
- From
John Tapsell <johnflux@gmail.com>
- Date
- Jun 17, 2009, 16:40 UTC
- Message-ID
- <43d8ce650906170940m17942793xe0cd88ae372ff8f2@mail.gmail.com>
- In-Reply-To
- <7vvdmurfao.fsf@alter.siamese.dyndns.org>
2009/6/17 Junio C Hamano <gitster@pobox.com>:
Show 41 quoted lines
> John Tapsell <johnflux@gmail.com> 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.