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

[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

and then I'll need to edit the commit message for the first two combined.
More than half of the time (but not necessarily all the time), the edit
involves just removing the single-liner 'squash to "clean up"',

You _could_ work this way instead using "amend".  Immediately after
finishing the three-patch series:

	$ git rebase -i HEAD~4

which gives me

        pick 1/3 Clean up ...
        pick 2/3 Lay the groundwork
        pick 3/3 Implement

that I'll change to

        edit 1/3 Clean up ...
        pick 2/3 Lay the groundwork
        pick 3/3 Implement

and then perform extra clean-up when "rebase -i" let's me amend the first
one.

But this is much less convenient than being able to accumulate fix-ups as
separate commits on top of the mostly finished main series, and then being
able to later insert these fix-ups into the main series to be squashed
using "rebase -i", if (and only if) what you need to do are many small
fixups (imagine there are not just a single '[4/3] squash to "clean up"'
but a lot more fix-up commits in the above example).  Depending on the
style you work, "go back to amend" is Ok, or you may even prefer to.  But
some people do not switch context as rapidly as others.  After finding a
small "missed piece", having to go back to edit and come back is much more
heavyweight operation than being able to make a small "fix-up" commit on
top and keep going.  The latter keeps your thought process less disrupted.

And it is very likely that the "small fixups" won't change what the
original commit log message of the commit in the main needs to say
(otherwise they won't be "small").

So I can see why a variant of "squash" that does not change (nor even ask
for a replacement of) the commit log message from the one that is being
amended could be useful.  I am tempted to suggest calling that a "fixup"
operation, but some people may expect "fixup" to mean a variant of "edit"
that does not bother you by dropping you back to the shell to touch the
tree that is recorded (i.e. "fixing up the commit log message only"), so
it is not a very good word.