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

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



On 10/07/2014 11:40 AM, Sean Farley wrote:
>
> 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.

Quick dance to highlight we agree on some of this ;-)

>> 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.

But X^-1 and X^-2 are going to be unreliable over time (see my other email).

The reason as why I'm asking for usecase is because I, as a hardcore and 
long term user of evolution an hiking along the graph, have rarely been 
found in situation where I could reliably count on children(x).

> 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:

(Lets index each paragraph 1, 2 and 3)

I would like to hear more about your bisect usecase (2).

(1) and (3) seems similar to me. In both case, I read them as "I want to 
select the "next" changesets (target of `hg next`). (For (3) this 
requires issue4390 to be implemented).

And given that `hg next` could not stay a simple as `hg up children(.)` 
I'm doubting that an operator for `children` will do the trick here.

Augies proposal made me think that -maybe- we need a `next(x)` revset. 
See other emails for details.

I'm eager to ear about your bisection case.

-- 
Pierre-Yves David

ps: http://bz.selenic.com/show_bug.cgi?id=4390



More information about the Mercurial-devel mailing list