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

Sean Farley sean.michael.farley at gmail.com
Tue Oct 7 13:40:02 CDT 2014


Pierre-Yves David writes:

> On 10/04/2014 09:57 AM, Sean Farley wrote:
>> # HG changeset patch
>> # User Sean Farley <sean.michael.farley at gmail.com>
>> # Date 1412441841 25200
>> #      Sat Oct 04 09:57:21 2014 -0700
>> # Node ID c3bd6d6457bf42d2fbcaba89cf0418a0d0604239
>> # Parent  78c916f24dd99a56e4c29153a5df3bd7d1c40edd
>> revset: allow negative integers to list child revs
>
> Quick reply on various subject.
>
> As X^1 and X^2 return a single revision (per X) (short version for p1(X) 
> and P2(X)) It would be a bad idea to have X^-1 return multiple revision.

I agree.

> first(children(X)) have less good defined semantic as first(parents(X)) 
> as it no deterministic and will change over time. the first parent of a 
> changeset is carved in stone. The amount of Children change over time 
> and with history rewriting, their order change over time. So you cannot 
> really predict the order. You need to (a) have one parent or (b) look 
> the number up (c) use a more precise revsets:
>    children(X) and ::bookmarkname
>    children(X) and desc(yyy)

They should always be returned in the revlog order. That is what we
currently do with referring to children via revision numbers. This would
be no added confusion.

> With evolution, the children revset become less useful when you have 
> unstable changeset. Because you may have obsolete or non obsolete 
> children. (hg next was an alias for `hg log --rev `children(.) - 
> obsolete()` for some time). Handling this requires to use more complex 
> revsets.

Yes, evolution does throw a wrench into thing but that's another patch
series.

> Given all the issue above, I'm not convinced about the benefit of a 
> children append notation. We'll have to mix it with other revset to get 
> something useful in a lot of case. I agree that children(X) is a bit 
> cumbersome. So I support the mpm proposal for c(x))ion so much.

Anyone can use revset alias to make 'c' into 'children'. That's not the
point here.

> However, I'm curious about your use case. Can you details them? So that 
> we have a better idea of the issue you are trying to solve here ?

There are many, many cases of navigating relative to the currently
checked out revision '.'. Given the following DAG:

A <-- X <-- C
B <-/   \-- D

Where A and B are parents of X, and C and D are children of X, where X
is my current changeset, we can (with this proposal) refer to each
changeset A, B, C, and D with X^1, X^2, X^-1, X^-2, respectively.

The most common case for this (and the reason I wrote this patch) was
when I was patch reviewing via 'hg prev' / 'hg next'. So, I would end up
in the middle of some line of history and would want to see the diff of
the next child.

Though, this is not the only case, it is a common one for me (bisection
being another frequent one).

As another (future) example, let's pretend we have '<-' and '->' mean
successor and precursor, respectively, then referring to the changeset
that 'hg evolve' would rebase onto our current changeset:

hg log -r .->^-1

I don't think -> is a good operator but this is just an example.


More information about the Mercurial-devel mailing list