[PATCH 7 of 8 V2] revset: add origins() predicate

[Matt Mackall]

On Sun, 2012-07-01 at 21:14 -0400, Matt Harbison wrote:
> Matt Mackall wrote:
> > On Sat, 2012-06-23 at 01:21 -0400, Matt Harbison wrote:
> 
> [snip]
> 
> >> For the sake of this, let there be a cset X, which when copied creates
> >> cset Y, which when itself is copied creates Z.  Copy can be any of the
> >> three ops.  And let's use "origin(x)" means "the origin of x".  The
> >> possible results follow, with alternate 2 being the naive/simplest result:
> >>
> >> A) Where did X come from?
> >>
> >>      Op      Preferred       Alternate 1    Alternate 2
> >> origin(X)    {}               same           same
> >> origin(Y)    {X}              same           same
> >> origin(Z)    {X, Y} *         {X}             {Y}
> >
> > I tend to prefer {X} here.
> >
> 
> Seems reasonable, I'll give it a shot.  Is your rationale that it 
> supports C and D below better?
> 
> >> B) Where did X go?
> >>
> >>      Op             Preferred    Alternative 1     Alternative 2
> >> destination(X)     {Y, Z} *        {Z}               {Y}
> >> destination(Y)     {Z} **          same              same
> >> destination(Z)     {}              same              same
> >
> > But not sure about this. If I have branches dev, 1.0 and 2.0, and I
> > graft dev->2.0->1.0, then ask about destinations of dev cset, I want to
> > hear about both.
> >
> 
> I completely agree.
> 
> >> * I prefer this because it is symmetric with the preferred definition of
> >> origin (i.e. showing all the hops), and it is the only result possible
> >> if the copy operations were grafts (since Y and Z both point directly to
> >> X).  I don't like exposing the implementation differences between copy
> >> ops to the user.  The downside is "origin(destination(X))" == {X, Y},
> >> which Matt noted isn't desirable, though maybe this case isn't "simple"
> >> because of the "copy of a copy" scenario.
> >>
> >> ** Notice that if both copies were grafts, the result is {}, and there's
> >> nothing that can be done about it.
> >>
> >>
> >> C) What duplicates of X exist?
> >>
> >>      Op             Alternative 1    Alternative 2
> >> duplicate(X)      {Y, Z}           {X, Y, Z}
> >> duplicate(Y)      {X, Z}           {X, Y, Z}
> >> duplicate(Z)      {X, Y}           {X, Y, Z}
> >>
> >> I don't have a preference here.  Excluding the parameter from the result
> >> means that duplicate(all()) can't find all duplicates anywhere, because
> >> the result is always {}.
> >
> > We have some precedents here:
> >
> >   ancestors(X) = {X, ...}
> >
> > I don't have a strong opinion, though. But I'm really not sure about
> > this name.
> 
> I was trying to avoid 'copy/copies' like you mentioned before.  But I'm 
> not overly attached to it.  'clones' seems bad because it overloads the 
> command with the same name, to mean something entirely different.
> 
> > It's only going to find duplicates made by
> > graft/transplant/etc., not anything produced 'manually'. And that will
> > disappoint people. Silly people.
> >
> 
> Manually?  As in:
> 
> $ hg update some_version
> $ hg revert --all -r another_version
> $ hg ci

As in two different people applying the same patch, the sort of thing
that everyone would agree is a duplicate today, but isn't tracked as a
duplicate.

All I'm saying is that people WILL expect something named duplicate() to
find duplicates and will file bugs when it doesn't. That's just how it
is.

> So I guess the question is, how do we get the user to think about this 
> properly?

I'm not yet convinced we need it. Let's get the basics in and see what
happens.

> As an aside, I know there's a code freeze coming up, and I know you have 
> a backlog of things to review, though I can't tell how much.  Assuming a 
> freeze on or about the 15th, at what point before then does submitting 
> more stuff for default become just undesirable clutter on the ML?

I'll try to get down to zero by the freeze.

-- 
Mathematics is the supreme nostalgia of our time.