Is there an extension with a revset for 'all ancestors along the p1 line'?

[Gregory Szorc]

On Sun, Jun 5, 2016 at 2:02 AM, Sietse Brouwer <sbbrouwer at gmail.com> wrote:

> (Apologies, Gregory, I forgot to copy my reply to the list.)
>
> On 04/06/2016, Gregory Szorc <gregory.szorc at gmail.com> wrote:
>
> > Such a revset does not exist. Even if you built one, it wouldn't do what
> > you think. The reason is that Mercurial sorts the parent nodes during a
> > merge commit and stores the node with the smaller bit-wise value in p1.
>
> Are you certain that that is what Mercurial does? For tag 3.8.2, This
> is how I read merge.py, def update:
>

It looks like I'm wrong. I must have been thinking of the hashing code
(which does sort):
https://selenic.com/repo/hg/file/118a605e3ad9/mercurial/revlog.py#l94


>
> * line 1439 sets p1 to parent 1 of the current commit -- this is
> before this function sets the current commit's parents.
> * line 1465 aborts if the current commit already has more than 1
> parent -- in other words, when line 1439 sets p1 successfully, it sets
> it to the 'current' parent.
> * line 1453 sets `p2 = repo[node]`; `node` is the command-line
> argument passed to `hg merge` (you can check this by following
> commands.py def merge > hg.py def merge > merge.py def update), so
> that is always the incoming commit.
>
> As a sanity check, I tried creating two heads and merging them both
> ways: once merging 1 into 2, and once merging 2 into 1. When I then
> used `hg log` to print p1 and p2 of each commit, I found the two
> merges had different p1/p2-ordering: in each case, p1 was the
> 'receiving' parent, and p2 the incoming one.
>
>     hg --version
>     Mercurial Distributed SCM (version 3.8.2+20160517)
>
>     hg log -T '{rev}\np1: {p1rev}\np2: {p2rev}'
>     @    4  merge 2 into 1
>     |\   p1: 1
>     | |  p2: 2
>     +---o  3 merge 1 into 2
>     | |/   p1: 2
>     | |    p2: 1
>     | o  2
>     | |  p1: 0
>     | |  p2: -1
>     o |  1
>     |/   p1: 0
>     |    p2: -1
>     o  0
>        p1: -1
>        p2: -1
>
> If this looks alright to you, too, that would mean the p1/p2 distinction is
> indeed meaningful, which would be good news.
>
> Cheers,
> Sietse
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20160605/8cae92b4/attachment-0002.html>