This is an archive of the discontinued Mercurial Phabricator instance.

Differential D2396

stack: import Evolve stack test file
ClosedPublic

Authored by lothiraldan on Feb 23 2018, 5:36 AM.

Details

Reviewers
indygreg
Group Reviewers
hg-reviewers
Commits
rHG407934a97bc7: stack: import Evolve stack test file
Summary

Import Evolve stack test file for starting to have good coverage on stack
definition.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

lothiraldan created this revision.Feb 23 2018, 5:36 AM
indygreg added a subscriber: indygreg.Feb 23 2018, 9:39 PM

I haven't looked at the remainder of the series, but it feels weird to basically reinvent a special case of hg log as a debug command. I do see there is a commit introducing a revset for stack. Perhaps we could move it up in the series so we don't need what might be a not-very-useful debug command?

lothiraldan updated this revision to Diff 6213.Feb 28 2018, 6:59 PM
indygreg added a subscriber: yuja.Mar 19 2018, 3:59 PM
indygreg accepted this revision.
indygreg added inline comments.
mercurial/revset.py
1536

I'm not sure if the predicate should be prefixed with an underscore to mark it as internal. My reading of the help code is that the lack of a docstring will hide it from the docs.

I /think/ this is OK. But I wouldn't be surprised if @yuja or someone told me it needs changed. I'll queue this for now. We can always fix it up later if it is a problem.

This revision is now accepted and ready to land.Mar 19 2018, 3:59 PM
Closed by commit rHG407934a97bc7: stack: import Evolve stack test file (authored by lothiraldan). · Explain WhyMar 19 2018, 4:06 PM
This revision was automatically updated to reflect the committed changes.
martinvonz added a subscriber: martinvonz.Mar 20 2018, 3:33 PM
martinvonz added inline comments.
tests/test-stack.t
81

What if this was @ in the hg repo and only commits 4 and 5 were my own, then I would not want it to be part of my stack. It feels like a definition of upstream would be very helpful. Perhaps a way of providing a separate upstream per commit would be useful. Let's say upstream() was a revset, then I feel like something like "only(., upstream(.))" would be my stack. Of course, it gets weird if I have a history like we have here and I have defined the upstream of 4 to be 2 and the upstream of 5 to be 3 (or the other way around). I guess only commits that share an upstream can be part of the same stack.

96–108

I think I would have preferred to see all of these in my stack rather than just commit 6. Would you?

yuja added inline comments.Mar 21 2018, 10:14 AM
mercurial/revset.py
1536

If it's internal (i.e. shouldn't be accessible by user), _stack() is preferred.
If it's just experimental, it can be hidden by "(EXPERIMENTAL)"
in docstring.

1541

Nit: I prefer stackmod. and name the revset function as stack().

yuja added inline comments.Mar 21 2018, 10:29 AM
mercurial/revset.py
1549

This breaks the order of tip:0 & stack() for example, and is moot
since 68fcc5503ec5, which makes stacks follow the standard order.

lothiraldan added inline comments.Apr 5 2018, 11:35 AM
tests/test-stack.t
96–108

The goal of this series is to define a clean stack definition API. We started by reusing the existing bits from histsedit and show stack.

I've added a first way to configure the stack definition through configuration. I think seeing all the drafts is a good idea and we will works in a later series to have a way to include them in the stack.

lothiraldan marked 3 inline comments as done.Apr 5 2018, 12:24 PM
lothiraldan added inline comments.
mercurial/revset.py
1549

I have send a follow-up https://phab.mercurial-scm.org/D3136

Revision Contents
Changeset List

PathPackages
Mmercurial/revset.py (16 lines)
AMtests/test-stack.t (253 lines)

Diff 7125

mercurial/revset.py

pathutil, pathutil,
phases, phases,
pycompat, pycompat,
registrar, registrar,
repoview, repoview,
revsetlang, revsetlang,
scmutil, scmutil,
smartset, smartset,
stack,
util, util,
) )
from .utils import dateutil from .utils import dateutil
# helpers for processing parsed tree # helpers for processing parsed tree
getsymbol = revsetlang.getsymbol getsymbol = revsetlang.getsymbol
getstring = revsetlang.getstring getstring = revsetlang.getstring
getinteger = revsetlang.getinteger getinteger = revsetlang.getinteger
@predicate('secret()', safe=True) @predicate('secret()', safe=True)
def secret(repo, subset, x): def secret(repo, subset, x):
"""Changeset in secret phase.""" """Changeset in secret phase."""
# i18n: "secret" is a keyword # i18n: "secret" is a keyword
getargs(x, 0, 0, _("secret takes no arguments")) getargs(x, 0, 0, _("secret takes no arguments"))
target = phases.secret target = phases.secret
return _phase(repo, subset, target) return _phase(repo, subset, target)
@predicate('stack([revs])', safe=True)
indygregUnsubmitted
Not Done

I'm not sure if the predicate should be prefixed with an underscore to mark it as internal. My reading of the help code is that the lack of a docstring will hide it from the docs.

I /think/ this is OK. But I wouldn't be surprised if @yuja or someone told me it needs changed. I'll queue this for now. We can always fix it up later if it is a problem.

indygreg: I'm not sure if the predicate should be prefixed with an underscore to mark it as internal. My…
yujaUnsubmitted
Done

If it's internal (i.e. shouldn't be accessible by user), _stack() is preferred.
If it's just experimental, it can be hidden by "(EXPERIMENTAL)"
in docstring.

yuja: If it's internal (i.e. shouldn't be accessible by user), `_stack()` is preferred. If it's just…
def _stack(repo, subset, x):
# experimental revset for the stack of changesets or working directory
# parent
if x is None:
stacks = stack.getstack(repo, x)
yujaUnsubmitted
Done

Nit: I prefer stackmod. and name the revset function as stack().

yuja: Nit: I prefer `stackmod.` and name the revset function as `stack()`.
else:
stacks = smartset.baseset([])
for revision in getset(repo, fullreposet(repo), x):
currentstack = stack.getstack(repo, revision)
stacks = stacks + currentstack
# Force to use the order of the stacks instead of the subset one
return stacks & subset
yujaUnsubmitted
Not Done

This breaks the order of tip:0 & stack() for example, and is moot
since 68fcc5503ec5, which makes stacks follow the standard order.

yuja: This breaks the order of `tip:0 & stack()` for example, and is moot since 68fcc5503ec5, which…
lothiraldanAuthorUnsubmitted
Not Done

I have send a follow-up https://phab.mercurial-scm.org/D3136

lothiraldan: I have send a follow-up https://phab.mercurial-scm.org/D3136
def parentspec(repo, subset, x, n, order): def parentspec(repo, subset, x, n, order):
"""``set^0`` """``set^0``
The set. The set.
``set^1`` (or ``set^``), ``set^2`` ``set^1`` (or ``set^``), ``set^2``
First or second parent, respectively, of all changesets in set. First or second parent, respectively, of all changesets in set.
""" """
try: try:
n = int(n[1]) n = int(n[1])

tests/test-stack.t

  • This file was added.
This test test the low-level definition of stack, agnostic from all formatting
Initial setup
$ cat << EOF >> $HGRCPATH
> [ui]
> logtemplate = {rev} {branch} {phase} {desc|firstline}\n
> [extensions]
> rebase=
> [experimental]
> evolution=createmarkers,exchange,allowunstable
> EOF
$ hg init main
$ cd main
$ hg branch other
marked working directory as branch other
(branches are permanent and global, did you want a bookmark?)
$ echo aaa > aaa
$ hg add aaa
$ hg commit -m c_a
$ echo aaa > bbb
$ hg add bbb
$ hg commit -m c_b
$ hg branch foo
marked working directory as branch foo
$ echo aaa > ccc
$ hg add ccc
$ hg commit -m c_c
$ echo aaa > ddd
$ hg add ddd
$ hg commit -m c_d
$ echo aaa > eee
$ hg add eee
$ hg commit -m c_e
$ echo aaa > fff
$ hg add fff
$ hg commit -m c_f
$ hg log -G
@ 5 foo draft c_f
|
o 4 foo draft c_e
|
o 3 foo draft c_d
|
o 2 foo draft c_c
|
o 1 other draft c_b
|
o 0 other draft c_a
Check that stack doesn't include public changesets
--------------------------------------------------
$ hg up other
0 files updated, 0 files merged, 4 files removed, 0 files unresolved
$ hg log -G -r "stack()"
@ 1 other draft c_b
|
o 0 other draft c_a
$ hg phase --public 'branch("other")'
$ hg log -G -r "stack()"
$ hg up foo
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
Simple test
-----------
'stack()' list all changeset in the branch
$ hg branch
foo
$ hg log -G -r "stack()"
@ 5 foo draft c_f
|
o 4 foo draft c_e
|
o 3 foo draft c_d
martinvonzUnsubmitted
Not Done

What if this was @ in the hg repo and only commits 4 and 5 were my own, then I would not want it to be part of my stack. It feels like a definition of upstream would be very helpful. Perhaps a way of providing a separate upstream per commit would be useful. Let's say upstream() was a revset, then I feel like something like "only(., upstream(.))" would be my stack. Of course, it gets weird if I have a history like we have here and I have defined the upstream of 4 to be 2 and the upstream of 5 to be 3 (or the other way around). I guess only commits that share an upstream can be part of the same stack.

martinvonz: What if this was @ in the hg repo and only commits 4 and 5 were my own, then I would not want…
|
o 2 foo draft c_c
|
~
Case with some of the branch unstable
------------------------------------
$ hg up 3
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ echo bbb > ddd
$ hg commit --amend
2 new orphan changesets
$ hg log -G
@ 6 foo draft c_d
|
| * 5 foo draft c_f
| |
| * 4 foo draft c_e
| |
| x 3 foo draft c_d
|/
o 2 foo draft c_c
|
o 1 other public c_b
|
o 0 other public c_a
martinvonzUnsubmitted
Not Done

I think I would have preferred to see all of these in my stack rather than just commit 6. Would you?

martinvonz: I think I would have preferred to see all of these in my stack rather than just commit 6. Would…
lothiraldanAuthorUnsubmitted
Not Done

The goal of this series is to define a clean stack definition API. We started by reusing the existing bits from histsedit and show stack.

I've added a first way to configure the stack definition through configuration. I think seeing all the drafts is a good idea and we will works in a later series to have a way to include them in the stack.

lothiraldan: The goal of this series is to define a clean stack definition API. We started by reusing the…
$ hg log -G -r "stack()"
@ 6 foo draft c_d
|
~
$ hg up -r "desc(c_e)"
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg log -G -r "stack()"
@ 4 foo draft c_e
|
x 3 foo draft c_d
|
~
$ hg up -r "desc(c_d)"
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg log -G -r "stack()"
@ 6 foo draft c_d
|
~
Case with multiple topological heads
------------------------------------
Make things linear again
$ hg rebase -s 'desc(c_e)' -d 'desc(c_d) - obsolete()'
rebasing 4:4f2a69f6d380 "c_e"
rebasing 5:913c298d8b0a "c_f"
$ hg log -G
o 8 foo draft c_f
|
o 7 foo draft c_e
|
@ 6 foo draft c_d
|
o 2 foo draft c_c
|
o 1 other public c_b
|
o 0 other public c_a
Create the second branch
$ hg up 'desc(c_d)'
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo aaa > ggg
$ hg add ggg
$ hg commit -m c_g
created new head
$ echo aaa > hhh
$ hg add hhh
$ hg commit -m c_h
$ hg log -G
@ 10 foo draft c_h
|
o 9 foo draft c_g
|
| o 8 foo draft c_f
| |
| o 7 foo draft c_e
|/
o 6 foo draft c_d
|
o 2 foo draft c_c
|
o 1 other public c_b
|
o 0 other public c_a
Test output
$ hg log -G -r "stack(10)"
@ 10 foo draft c_h
|
o 9 foo draft c_g
|
~
$ hg log -G -r "stack(8)"
o 8 foo draft c_f
|
o 7 foo draft c_e
|
~
$ hg log -G -r "stack(head())"
@ 10 foo draft c_h
|
o 9 foo draft c_g
|
~
o 8 foo draft c_f
|
o 7 foo draft c_e
|
~
Check the stack order
$ hg log -r "first(stack())"
10 foo draft c_h
$ hg log -r "first(stack(10))"
10 foo draft c_h
$ hg log -r "first(stack(8))"
8 foo draft c_f
$ hg log -r "first(stack(head()))"
8 foo draft c_f
Case with multiple heads with unstability involved
--------------------------------------------------
We amend the message to make sure the display base pick the right changeset
$ hg up 'desc(c_d)'
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ echo ccc > ddd
$ hg commit --amend -m 'c_D'
4 new orphan changesets
$ hg rebase -d . -s 'desc(c_g)'
rebasing 9:2ebb6e48ab8a "c_g"
rebasing 10:634f38e27a1d "c_h"
$ hg log -G
o 13 foo draft c_h
|
o 12 foo draft c_g
|
@ 11 foo draft c_D
|
| * 8 foo draft c_f
| |
| * 7 foo draft c_e
| |
| x 6 foo draft c_d
|/
o 2 foo draft c_c
|
o 1 other public c_b
|
o 0 other public c_a
We should improve stack definition to also show 12 and 13 here
$ hg log -G -r "stack()"
@ 11 foo draft c_D
|
~