2009/6/17 Junio C Hamano <gitster@xxxxxxxxx>: > John Tapsell <johnflux@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html