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

Simon Farnsworth simonfar at fb.com
Mon Mar 7 08:58:29 EST 2016

On 07/03/2016, 13:22, "Yuya Nishihara" <youjah at gmail.com on behalf of yuya at tcha.org> wrote:

>On Fri, 4 Mar 2016 08:31:40 -0800, Simon Farnsworth wrote:
>> # HG changeset patch
>> # User Simon Farnsworth <simonfar at fb.com>
>> # Date 1457034054 0
>> #      Thu Mar 03 19:40:54 2016 +0000
>> # Node ID f9c8bf605e5b96530f6a4636c78f9c444767c445
>> # Parent  9d6c19c8413a039aff8399d6b1db573cb6610fab
>> merge: improve conflict markers by pointing to introrev
>> If you're working in a fast moving repository, the nodes chosen for conflict
>> markers are apparently nonsensical - they're the revisions you're actually
>> merging, even if the file in conflict did not change in those revisions.
>> Change the conflict markers to find the introrev for local and other, and
>> use that as the node instead. This means that the conflict markers now point
>> to the commits in which the conflicting file was last changed.
>The default conflict marker includes {tags} and {bookmarks}. I don't think
>they should be changed to the introrev. Perhaps we'll need new template keyword
>for the introrev.

Why do you think that {tags} and {bookmarks} should be on the nodes being merged, not on the introrevs?

My reasoning for changing the node itself (hence also changing {tags} and {bookmarks}) is that when you're dealing with a merge conflict, you're not interested in the merge heads themselves - in the common cases, you either know exactly which nodes are being merged (because you're merging two trees of your own work together), or one is familiar (your own work), and the other is random (because you don't know the state of the remote tree at the point you did "hg pull"). Having the tags and bookmarks in the conflict marker come from the introrev means that I get told if the conflict happened at an interesting point in the tree. For slow-moving trees, this is uninteresting information - the introrev of a conflict is the same as the merge revision, because I simply don't get many conflicts in the first place; it's once you get into fast moving trees that conflicts get interesting, and in those cases, the merge nodes are pseudo-random anyway.

I'm interested in other use cases I've not considered - if you'd prefer to discuss on IRC, I'm "farnz" on #mercurial, and I tend to be around from 1100 to 1800 UTC Monday to Friday.


More information about the Mercurial-devel mailing list