[PATCH 2 of 2 V2] revset: new predicates to find key merge revisions

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Mar 10 08:51:53 EST 2016



On 03/10/2016 10:12 AM, Simon Farnsworth wrote:
> On 10/03/2016, 00:17, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org> wrote:
>
>
>> On 03/07/2016 06:27 PM, Simon Farnsworth wrote:
>>> # HG changeset patch
>>> # User Simon Farnsworth <simonfar at fb.com>
>>> # Date 1457374657 0
>>> #      Mon Mar 07 18:17:37 2016 +0000
>>> # Node ID faf1fd7f7079801368317a681f55dbc46e878de0
>>> # Parent  d92485c84727d67bcbf462b26dcfc1b7c746d07d
>>> revset: new predicates to find key merge revisions
>>>
>>> When you have tricky merge conflicts, it's useful to look at the history of
>>> the conflict. In a fast moving repository, you're drowned in revisions that
>>> are in the merge but that can't impact on a conflict.
>>>
>>> Provide a new revset predicate to help out; conflict(type, pat) allows you
>>> to find the "base", "other" or "local" revision types for the merge
>>> conflicts identified by pat. This, in turn, enables you to write revsets to
>>> find all revisions that are of interest in a conflict situation.
>>
>> I'm a bit confused about this.
>>
>> Is there situation where "local" is not p1() and "other" is not p2()
>> (except for "update" merge were "local" does not exist)? If not, I'm not
>> sure why we need this predicate for them.
>
> These two predicates point you to the introrev of the conflict, not the merge points. I can clarify the commit message in a V3 submission. The goal is that between base, local, other, p1() and p2(), you have all the points you need to write revsets that find you interesting commits from the point of view of a human resolving the commit; for example, 'conflict("base", "file"):conflict("other", "file")' is all commits from the three way merge base to the latest change on the other side that could have caused the conflict.

As said in another thread, I'm not super eager to promote "introrev" as 
the one relevant for the "conflict" too much. especially because it is 
already accessible using last(::p1() and file(FILENAME)).

If having access introrev is really useful (for speed?) we could 
probably add a keyword argument to the 'file()' revset to restrict the 
search to a specific file revision.

>> What does "base" return exactly, I could not really infer it from the
>> documentation.
>
> It's the common ancestor of the two commits being merged - we call it "base" elsewhere in merge documentation, so I've kept that name rather than ancestor.

I know what's the general meaning of "base" in a merge context, but what 
are you returning here? the changeset common ancestor of the introrev of 
that version? Also, there might be more than one common ancestors so It 
is unclear to me how you behave in this case.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list