Re: rebase -p loses amended changes

Jon Seymour [off-list ref] writes:

It'd be quite expensive to attempt to detect cases where this might be
a problem, but let's articulate, as a thought experiment, what such a
solution might look like - I am not suggesting that it is a good idea,
but the thought experiment might be illustrative.

Suppose you have a merge of a A and B that produces M, which is then
amended as M'.

During rebase, you redo the merge A and B. If there are no conflicts,
then compare M with M' to produce D. You now have enough information
to reproduce the amended commit M' during a rebase (merge Ar and,Br
then apply D).

Not necessarily.  You realized yourself a half of it.

What isn't clear to me, in this thought experiment, is how you might
attempt to solve the case where there were syntactic (as opposed to
semantic) conflicts between the merge of A and B originally. You have
no idea, at that point, how the user originally resolved the conflicts
to produce M, thus no idea how to calculate D or even if there was a
non-trivial D.

True.  The other half of the issue is that the merge heuristics may have
improved between the version of Git used to originally create M and the
version of Git used when you are attempting the rebase.  The original one
may have given a clean but incorrect merge, and your trial merge during a
rebase may have given a clean and correct merge.  The patch D may be the
right fix-up to apply to M, but it may not be if applied to M'.

In short, it is not "quite expensive", but is fundamentally impossible.