(1) How to detect criss-cross (2) is ancestor(*changeset) always the "base" of merges

[Giovanni Gherdovich]

Hello,

I'll use a few names that I'm not sure are universal,
so my definitions:

LCA (Lowest Common Ancestor) of nodes X,Y:
     a common ancestor A of X and Y such that
     no descendant of A is also a common ancestor of X and Y.
     As far as I understand, LCA(X,Y) is chosen as "base" when
     performing 3-way merge.

Criss-Cross merge: when one wants to merge D and E but
     LCA(D,E) is not unique, the situation is called "criss-cross merge".
     As in the picture below (please monospaced fonts), where history
     flows from top to bottom, it can happen when developers
     pull from each other and then merge back together.

   A
  / \
 B   C
 |\ /|
 | X |
 |/ \|
 D   E
  \ /
   F


Questions:
   (1) people FUD-y thinks that "criss-crossing" implies "troubles ahead".
       Well, I do. My (poor) intuition is that whatever "base" I choose
       it isn't gonna be... "the best", so I am gonna observe more conflicts
       than "necessary".
       ----> Is this "fear" of criss-crossing justified?
             Are they really a Bad Thing that you should try to avoid in
your workflow?

       Beware, I am not trolling about recursive merging[1] (git's
strategy) or
       consensus merge[2], I have read the reference below.
       [1] http://selenic.com/pipermail/mercurial/2012-January/041456.html(Matt
on Recursive Merge Strategy)
       [2] http://mercurial.selenic.com/wiki/ConsensusMerge

   (2) Is there a way to use revset queries in order to detect if a merge
is gonna be criss-cross?
       Or some other way to build a criss-cross detector that isn't too
hard to implement.

   (3) How to ask mercurial "what is the 'base' you will use for this
merge" ?
       The "ancestor(*changeset)" revset function gives the "Greatest
common ancestor of the changesets",
       is that function wired to the very same algorithm that selects
"base" in a merge?

Cheers,
GGhh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20131229/c649ee25/attachment-0002.html>