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