Jon Seymour <jon.seymour@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html