[PATCH 4 of 4] revset: introduce a 'foo#stack[n]' subscript relation to access stack revisions

[Pierre-Yves David]

Yuya and I talked about it at the sprint. The conclusion that that both 
the `r#stack` and `r#stack[base]` approach are valid. We are leaning 
toward using `r#stack`.

Anton, can you move in that direction ?

On 9/27/19 12:13 PM, Pierre-Yves David wrote:
> 
> 
> On 9/25/19 2:04 PM, Yuya Nishihara wrote:
>> On Wed, 25 Sep 2019 18:20:11 +0800, Anton Shestakov wrote:
>>> On Wed, 25 Sep 2019 02:48:09 +0200
>>> Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>>>> On 9/25/19 1:25 AM, Yuya Nishihara wrote:
>>>>> On Tue, 24 Sep 2019 21:16:53 +0200, Pierre-Yves David wrote:
>>>>>> On 9/23/19 2:58 PM, Yuya Nishihara wrote:
>>>>>>> On Mon, 23 Sep 2019 10:39:52 +0700, Anton Shestakov wrote:
>>>>>>>> # HG changeset patch
>>>>>>>> # User Anton Shestakov <av6 at dwimlabs.net>
>>>>>>>> # Date 1569139969 -25200
>>>>>>>> #Â Â Â Â Â  Sun Sep 22 15:12:49 2019 +0700
>>>>>>>> # Node ID ab8f097abacb8ce0f9cea2bce0924bb2fd3261a2
>>>>>>>> # Parent  07af98a1e730c1ffa6911c9ab2cdcc06d4ffe52d
>>>>>>>> # EXP-Topic stack-object
>>>>>>>> revset: introduce a 'foo#stack[n]' subscript relation to access 
>>>>>>>> stack revisions
>>>>>>>>
>>>>>>>> The idea behind making n = 0 cases special is that stack base 
>>>>>>>> should be
>>>>>>>> accessible, but only when users ask for it explicitly.
>>>>>>>> +def stackrel(repo, subset, x, rel, z, order):
>>>>>>>> +Â Â Â  a, b = getintrange(z,
>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  _('relation subscript must be an integer 
>>>>>>>> or a range'),
>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  _('relation subscript bounds must be 
>>>>>>>> integers'),
>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  deffirst=None,
>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  deflast=None)
>>>>>>>> +
>>>>>>>> +Â Â Â  s = getset(repo, fullreposet(repo), x)
>>>>>>>> +Â Â Â  if not s:
>>>>>>>> +Â Â Â Â Â Â Â  return baseset()
>>>>>>>> +
>>>>>>>> +Â Â Â  def getrange(st, a, b):
>>>>>>>> +Â Â Â Â Â Â Â  start = 1 if a is None else a
>>>>>>>> +Â Â Â Â Â Â Â  end = len(st.indexedrevs) if b is None else b + 1
>>>>>>>
>>>>>>> I feel it's weird that stack[:] doesn't include stack[0].
>>>>>>
>>>>>> [0] is the "root" of the stack, but not part of it. It is handy to 
>>>>>> have
>>>>>> it around when one want to insert and initial commit or test thing
>>>>>> without any of the stack changes, however it not part of the stack.
>>>>>>
>>>>>> For example if you want to update all changesets in the stack you 
>>>>>> could
>>>>>> do `hg metaedit --rev '.#stack[:]' --user foobar`. You don't want to
>>>>>> select s0 it might even be a public changesets.
>>>>>
>>>>> I understand that. My point is it may be confusing if foo[:] 
>>>>> includes #foo[0],
>>>>> but #bar[:] doesn't.
>>>>
>>>> I suspect we already have a "every namespace behave differently
>>>> situation". The "generation" namespace is not table indexing 
>>>> ".#g[0]" is
>>>> ".", and ".#g[X]' might return more than on revision.
>>
>> Yep, but I feel x[:] should return everything in 'x' because the range
>> operator works in that way.
>>
>>> Yeah, the problem with handling [0] in this special way is usability.
>>> We do want to access stack base sometimes, but it's also not a part of a
>>> stack. So we obviously can't leave it to users to just write a revset to
>>> pick stack base, but it's also cumbersome to write "foo#s[:] - foo#s[0]"
>>> every time you want to pick the whole stack.
>>
>> Just 'foo#s[1:]'?
>>
>>> Maybe removing subscript
>>> would make it more special (and somewhat less confusing), like
>>> "foo#stack"? That's my only idea so far, and I'm not a fan of it.
>>
>> Another (somewhat weird) idea. foo#stack[base] to populate the base 
>> revision.
>> The 'base' symbol is something like 'null' in plain revsets. Say, it's 
>> the -1
>> index, but -$integer is handled as a negative array indexing, so only 
>> the 'base'
>> symbol can allow us to access the stack[-1] value.
> 
> That would work. the "0" value is special, so we can use special symbol. 
> It could also open the door to express base for other roots (when the 
> stack is not linear (yet)).
> 
> That said, I feel it is important to keep stack index starting at 1 (so 
> no using 0 at all). Most UI we already have around stack/series (eg: 
> patchbomb) start indexing to #1)
> 
> 

-- 
Pierre-Yves David