On Fri, Sep 2, 2016 at 9:22 PM, Junio C Hamano <gits...@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.
If it did this, then later when I'm ready to merge and all contributions upstream are completed, I would most likely lose track of which original commit to fixup to. This would only be an issue if you gave the option to reword the "fixup! original". Rewording it, to me, inherently means you no longer want to meld it into another commit and instead intend on it being independent (looking at this semantically, without relying on translating the commit message itself, even though it may clearly tell me to squash it to something else, that's not as reliable as the fixup! mechanics IMHO). > - The search for "original" when handling "pick fixup! fixup! > original", could be (probably unconditionally) changed to look > for "fixup! original" to amend, instead of looking for "original" > as the current code (this is your "separate issue"). The same > "if the commit to be amended is not found, turn it into reword" > rule from the above applies to this one, too. So this is mostly for my education, since I don't see a difference from a user-standpoint. 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. 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.
