Re: Fixup of a fixup not working right

["Philip Oakley" <philipoakley@iee.org>]

Hi Robert,
From: "Robert Dailey" <rcdailey.lists@gmail.com>
> On Fri, Sep 2, 2016 at 9:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Perhaps a change like this to "rebase -i":
>>
>>  - The search for "original" when handling "pick fixup! original",
>>    when it does not find "original", could turn it into "reword
>>    fixup! original" without changing its position in the instruction
>>    sequence.
>
[..]
> So this is mostly for my education, since I don't see a difference
> from a user-standpoint.

This was a problem in the past.

>   Why would "fixup! fixup! original" look for
> "original" instead of "fixup! original"? As far as I can see, the
> behavior would be the same and the order would be retained since you
> are essentially "chaining" the fixups together this way.

The patch that introduced the effect is 22c5b13 (rebase -i: handle fixup! 
fixup! in --autosquash, 2013-06-27). At the time it was possible that the 
commits would be re-ordered based on the full multi-fixup message, and so, 
if you thought you'd corrected a poor fixup, rather correcting the original, 
the conceptual order would change. While the combined diffs still notionally 
add to the same effect, the changes to the context lines may mean they don't 
apply cleanly - keeping them in order makes for a clean application. The 
solution was to ignore multiple fixup!s at the start.


> This also
> gives you the behavior you want directly because the algorithm will
> naturally tie to "fixup! original" even if "original" doesn't exist,
> because Git would expect that "fixup! original" will automatically
> manage its own order, and that subsequent processed nested "fixup!"
> commits would not need to depend on any other commits.

There is a question as to whether the commit you pushed upstream, is classed 
as 'published' and immutable, or still part of the review and modification 
process. At the moment the presumption, in general, is that it would be the 
former, so that you can't fixup the original. I don't see that changing, 
however Junio's suggestion that these extra fixups are 'reworded' so that 
they will rebase (--autosquash) locally to become one commit titled 
something like "fix! original", and then a final rebase that rewords that 
commit back to "fixup! " for pushing upstream to the 'review' process, where 
they can request that it be 'fixed';-)