"Philip Oakley" <philipoak...@iee.org> writes:
> As I understand this it's implied by design. The issue is that the
> rebase is looking for that named commit within its current rebase
> range, and can't find it, so ignores it.
> There is a separate issue that all the fixup! fixup! messages are
> essentially treated as being concatenations of the original fixup!, no
> matter how many time the fiup is present.
They can be handled separately, but they come from the same "design"
that could be improved. When the "original" is not in the range to
be rebased for whatever reason (including the most likely one, i.e.
it has already graduated to become part of the public history), the
best thing the user could do at that point may be, as you suggested
to Robert in your message, to turn the "fixup! original" that did
not make in time before "original" hit the public record into a
standalone "fix original" follow-up change, and then to squash
subsequent "fixup! fixup! original" (and other "fixup! original",
too) into that commit. And a good direction forward may be to see
if "rebase -i" can be taught to be more helpful for the user who
wants to do that.
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
- 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.
may be an improvement?