Re: git rebase --interactive squash/squish/fold/rollup

[John Tapsell <johnflux@gmail.com>]

2009/6/17 Junio C Hamano <gitster@pobox.com>:
> 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.