"Philip Oakley" <philipoakley@xxxxxxx> 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 sequence. - 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?