Re: rebase -p loses amended changes

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 3, 2012, 22:02 UTC
Message-ID: <7vwr5wbhk3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAH3Anrq_Z0V=DpU1iH-A3F8RFWTG0_C1hEe3iDZYe=AYDTRT3g@mail.gmail.com>

Jon Seymour <jon.seymour@gmail.com> writes:

Show 12 quoted lines

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

Show 6 quoted lines

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