Re: A couple of rebase --autosquash proposals

[Chris Packham <judge.packham@gmail.com>]

On 09/12/13 19:51, Johannes Sixt wrote:
> Am 12/9/2013 3:23, schrieb Brett Randall:
>> * fixup! or squash! on it's own would default to fixing-up the
>> previous commit (or result of previous step of rebase if that was a
>> squash/fixup).
> 
> Why would you want that? To fixup the previous commit, just use 'git
> commit --amend'. What am I missing?

In the past I've used this kind of approach when doing merging/porting
work with 3rd party code (or just large integrations). The first (and
eventually final) commit introduces the new code. The subsequent fixups
address build issues which are either errors in the 3rd party code
(which I will want to submit bug reports for later and carry in my tree
as real commits) or errors in my merging (which I want to squash into
the merge commit). When faced with a screen full of compilation errors
I'm not sure which of these 2 categories are applicable at the time so I
tend to have lots of little fixups that I need to juggle around with git
rebase once I've got the code compiling and passing some tests.

All that being said I think allowing multiple "fixup!\n" stack up on
each other might be a bit dangerous. There are cases where
fixup!-fixup!-real might be useful but those would be hard to
distinguish those from cases where someone absent mindedly forgot to put
something after "fixup!".