[PATCH] revset: allow negative integers to list child revs

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Oct 8 21:55:09 CDT 2014



On 10/07/2014 05:44 PM, Sean Farley wrote:
>
> Augie Fackler writes:
>
>> On Oct 7, 2014, at 4:12 PM, Sean Farley <sean.michael.farley at gmail.com> wrote:
>>
>>>>> Yes, of course, but this is derailing the current discussion. We have
>>>>> the concept of local revision numbers and this patch is a way to refer
>>>>> to that. I would suggest another discussion about the order of
>>>>> children().
>>>>
>>>> This is not to challenge the order of children(X). This is to point out
>>>> that children can barely be used alone and therefor having a supershort
>>>> version of it is not that useful.
>>>
>>> I'm surprised you are being this stubborn about it. It is very, very
>>> common to have a set of linear changes. It is even still common to be in
>>> a situation where you only have a reference to the parent of a
>>> changeset.

The things I'm fighting againts here, is feature creep. I'm not fan of 
adding new operator because:

1) We have a limited set of char that can be operator.
2) Rarely used operator makes revset harder to read since it is harder 
to remember "::" than to read "ancestors" out. Revset readability is an 
important argument for newbies.

So I'm questioning:

1) The necessity for an operator poking at children in general
2) The fact that this operator will be actually useful alone in most case.

This (2) is the reason why I'm stubborn at pointing all the issue with a 
children operator. And I'll keep pointing at them until I'm under the 
impression that people involved in that discussion have properly 
understood them.

This limitation themselves will maybe not get people to change their 
mind, but they should be aware of them before taking a decision.

>> I could see a claim that an "only child of" operator would be more useful than an "arbitrary child" operator (that is, abort if len(children) != 1). Maybe that'd be the useful middle ground here?

Things are a bit more complex that than. You can have multiple children, 
but only one is non-obsolete:

   o B'
   |
   | o C
   | |
   | x B
   | /
   |/
   A

This is the reason `hg next` exist in the first place. Because 
children(x) was not doing the job at rulling out obsolete changesets 
(and because I wanted ambiguity pointed out.)

Maybe a `next(X)` revset would be useful. It would return the target for 
`hg next` when no ambiguity exists. (I'm not sure what it would do in 
the face of ambiguity).

It could also grow capability to select the changeset that would be 
evolve by an `hg next --evolve` call.

> I really don't see the problem with an arbitrary child operator. For
> most cases, the use would be with one child.

You usecase for it seems very connected to evolution. Where it is fairly 
common end up with more than one changesets.

> If someone wants to use it
> for the second child, then that is also deterministic: ordered by local
> revnum.

Again. The order of children is not deterministic enough to be useful. 
Of course it is stable under exact same condition (because it is ordered 
by revnum). But it far much more unstable other stuff.

For example, `p1(e8832cf1abf6)` will always give you the same result. 
And this is even true in different repository. `children(e8832cf1abf6)` 
is not going to give stable results (in mutable history). While history 
is getting rewritten. revision number of (semantic) changeset changes.

   o   B: fix doc
   |
   | o A: add feature.
   \ /
    o  O: base

At some point of time `first(children(O))` will return `A: add feature`. 
And at some other point of time it may return `B: fix doc` (because `A` 
could have been touched in between, so its revnum was bumped).

Therefore, one can not blindly use children(x) to refer to one in many 
children. Because unlike X^1, X^-1 is not going to return stable result.

(end of explanation of why children give unstable result. Can I get you 
to acknowledge this?)

So whenever there is multiple children involved it is very likely that 
the user have to either:

a) Explicitly look the children
b) Use a more precise revset (eg: `children(x) and ancestors(y)`)

So, in my opinion, the benefit of a short operator is likely to get 
nullified by either and explicit reference (case a) or the need to build 
a complex revset anyway.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list