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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 17, 2009, 16:33 UTC
Message-ID: <7vvdmurfao.fsf@alter.siamese.dyndns.org>
In-Reply-To: <43d8ce650906170555m644564b3v3722168f7217c326@mail.gmail.com>

John Tapsell <johnflux@gmail.com> writes:

Show 11 quoted lines

>> 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.