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