[PATCH] merge: improve conflict markers by pointing to introrev

Simon Farnsworth simonfar at fb.com
Tue Mar 8 13:04:47 EST 2016

On 08/03/2016, 15:29, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org> wrote:

>On 03/08/2016 01:24 PM, Simon Farnsworth wrote:
>> On 08/03/2016, 12:41, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org> wrote:
>>>My general opinion on this "using introrev" business is that it is a red
>>> herring. Revision touching a file are likely to be numberous so print
>>> the latest one is going to marginaly help in some case and confuse user
>>> in all the other. I would rather see provided an easy way to see the
>>> "what revision touched that file on each side" information than trying
>>> to try to fit very complexe information into the limited conflict marker
>>> entry.
>> That's the goal of the extra revset predicates (separate patch series); by providing you with an easy route to find the three interesting points of a three way merge on a file (introrev of the local and other parts of the merge, and the base node), you have the tools to write a revset alias that gets you all the commits that touched unresolved files (for example):
>My point is that there is no such things as "the three interesting 
>points of a three ways merge". The last changeset touching a file have 
>no reason to be much more interesting than the second last one, etc…

In the context of Mercurial revsets, I disagree; we have the revset language for starting from boundary points and getting to interesting places in-between. It is unlikely that changes before the three way merge base are interesting, because that's the common ancestor point; similarly, changes after the most recent changes to a file in either side of the merge are unlikely to be interesting; if you have all three points, you can write (as I demonstrated in the context you've snipped) a revset expression that gets you all the interesting commits for a human merge.

You can then decide how to put these points together - do you ask Mercurial for the DAG between the base and both edge nodes, do you filter based on files touched (not just the file in merge conflict - you might, for example, want every commit touching a file that you think of as part of the same project as the file in conflict, for hints about the broader direction of development at the time), do you perhaps want to see some descendants of these nodes (and if so, which ones)?


More information about the Mercurial-devel mailing list