Re: Fixup of a fixup not working right

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Robert,
From: "Robert Dailey" <rcdailey.lists@xxxxxxxxx>
On Fri, Sep 2, 2016 at 9:22 PM, Junio C Hamano <gitster@xxxxxxxxx> 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';-)



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]