Re: Fixup of a fixup not working right

From: Philip Oakley <philipoakley@iee.org>
Date: Sep 3, 2016, 22:33 UTC
Message-ID: <539B8BADEBFE4539ADC8B7EB60B23B5B@PhilipOakley>
In-Reply-To: <CAHd499Bd7CHZ-O8HLd_iNnVNxz1C1=vO-4kxD80sEgBiesrMXg@mail.gmail.com>

Hi Robert,
From: "Robert Dailey" <rcdailey.lists@gmail.com>

Show 8 quoted lines

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

Show 6 quoted lines

> 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';-)