Merge conflicts about tuid HOT 2 CLOSED

Maybe the merge patch and, the aggregate of the changesets that make up the merge patch, can be compared to deduce a "delta patch" - defined as "the changes made to fix merge conflicts". This would be faster to apply; especially if the number of files touched by the delta is small.

Let me attempt some pseudo code: Usually we have a merge patch (M) be the application of multiple changesets (Ci):

M = C1 * C2 * C3 * ... * Cn

When there is a merge conflict, it is resolved by apply a delta patch:

M = C1 * C2 * C3 * ... * Cn * D

We can rearrange this equation to:

Kn * ... * K3 * K2 * K1 * M = D

where Ki is the inverse changeset of Ci

from tuid.

To get an inverse changeset Ki when there are no merge conflicts is no issue. We start from the current revision, get the last diff applied and dis-apply it by inverting the additions and subtractions.

But when there is a merge conflict, there is no way to know how the last diff was applied, because it might not have been applied, or even misapplied.

I think that the solution you propose is also trying to solve the inverse of the problem of (1)"How do we merge these patches into a single revision?". You may already recognize what I am getting at. We would have to solve the inverse problem, which requires solving the forward problem that is (1) which is not yet automated. There are existing tools for solving this problem that do so by modifying input (diffs), and checking how well the output (simulated merge) matches the result (true merge).

from tuid.