Re: A couple of rebase --autosquash proposals

[Philippe Vaucher <philippe.vaucher@gmail.com>]

> >> * 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!".


You guys probably already know about it, but there is `git commit
--fixup SHA1` to create !fixup commits intended for a particular
commit. I think using this feature solves all the problem the OP has?

Philippe