[PATCH 2 of 5] filemerge: indicate that local/other are p1/p2

Matt Mackall mpm at selenic.com
Thu Mar 24 18:15:36 EDT 2016

On Thu, 2016-03-17 at 21:00 +0000, Simon King wrote:
> > On 17 Mar 2016, at 16:02, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> > 
> > Something to watch out for with p1 and p2 is that Mercurial doesn't preserve
> > parent order: it sorts the nodes and first is p1.
> > 
> > I think this patch is referring to different parents, so it might be fine.
> > Then again, it does expose p1 and p2 to the docs, so...
> What exactly do you mean by this? I was always under the impression that
> during a merge, p1 was the revision that was checked out, and p2 was the
> revision specified in “hg merge” (and a quick test suggests that’s the case).
> Is it not guaranteed?

For the purposes of hash stability, we do sort the parents when calculating the
revision hash, under the theory that the contents of merge(a, b) ought to equal
merge(b,a) and not be distinct. This made more sense in paleo-Mercurial where
everything was intentionally symmetric, but things like branch names have mucked
that up. But we actually preserve the ordering of parents from the dirstate when
recording the index.

Mathematics is the supreme nostalgia of our time.

More information about the Mercurial-devel mailing list