This is an archive of the discontinued Mercurial Phabricator instance.

remotenames: add names argument to remotenames revset
ClosedPublic

Authored by pulkit on May 20 2018, 5:22 PM.

Details

Summary

This patch adds names argument to the revsets provided by the remotenames
extension. The revsets are remotenames(), remotebranches() and
remotebookmarks(). names can be a single names, list of names or can be empty too
which means it's an optional argument.

If names is/are passed, changesets which have those remotenames will be
returned.
If names are not passed, changesets from all the remotenames are shown.

Passing an invalid remotename does not throw error.

The name argument also supports pattern matching.

Tests are added for the argument in tests/test-logexchange.t

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

pulkit created this revision.May 20 2018, 5:22 PM
yuja added a subscriber: yuja.May 24 2018, 9:13 AM

+def _parsepaths(x):
+ """parses the argument passed in revsets as paths and return
+ them as a set or returns None if no path is specified"""
+
+ if not x:
+ return None
+
+ paths = set()
+ if x[0] in ('symbol', 'string'):
+ paths.add(x[1])
+ elif x[0] == 'list':
+ for t, p in x[1:]:
+ paths.add(p)
+ return paths

Use revsetlang.getlist() and apply .getstring() to each element, which
is more robust.

That said, the common idiom is to accept a literal/re pattern. See
revset.bookmark() for example.

I like the literal/re pattern idea. I think if this lands I can stop maintaining remotebranches, so I'd very much like to see it land.

yuja added a comment.Jun 27 2018, 9:09 AM

+@revsetpredicate('remotenames([path, ...])')

My proposal was remotenames([pattern]), just like bookmark(), tag(),
branch(), etc. If we want a convenient way to specify path prefix, we can
add it to the stringmatcher (e.g. 'remotenames("path:server2")'.) And
multiple paths can be specified as 'remotenames(x) + remotenames(y)', though
it isn't exactly the same as 'remotenames("re:<x>|<y>")'.

Does it make sense?

In D3639#60108, @yuja wrote:

+@revsetpredicate('remotenames([path, ...])')

My proposal was remotenames([pattern]), just like bookmark(), tag(),
branch(), etc.
If we want a convenient way to specify path prefix, we can
add it to the stringmatcher (e.g. 'remotenames("path:server2")'.)

No, I don't want to specify a path prefix. remotenames() will take a path only. Do you want to say that we should allow passing full remotenames instead of just path?

yuja added a comment.Jun 29 2018, 8:55 AM
> > +@revsetpredicate('remotenames([path, ...])')
>
> My proposal was `remotenames([pattern])`, just like bookmark(), tag(),
>  branch(), etc.
>  If we want a convenient way to specify path prefix, we can
>  add it to the stringmatcher (e.g. 'remotenames("path:server2")'.)
No, I don't want to specify a path prefix. remotenames() will take a path only. Do you want to say that we should allow passing full remotenames instead of just path?

Yes, because a remote branch is merely a branch pulled from peer for example,
and we'll probably want to select it by -r remotebranch("foo/bar") just like
-r branch("foo/bar") for normal branches. Do I get it wrong? Why is it so
important to filter by a peer path, not by a branch name itself?

pulkit added a comment.Jul 1 2018, 5:13 PM
In D3639#60247, @yuja wrote:
> > +@revsetpredicate('remotenames([path, ...])')
>
> My proposal was `remotenames([pattern])`, just like bookmark(), tag(),
>  branch(), etc.
>  If we want a convenient way to specify path prefix, we can
>  add it to the stringmatcher (e.g. 'remotenames("path:server2")'.)
No, I don't want to specify a path prefix. remotenames() will take a path only. Do you want to say that we should allow passing full remotenames instead of just path?

Yes, because a remote branch is merely a branch pulled from peer for example,
and we'll probably want to select it by -r remotebranch("foo/bar") just like
-r branch("foo/bar") for normal branches. Do I get it wrong? Why is it so
important to filter by a peer path, not by a branch name itself?

You definitely get it right. I was unable to think that before your last comment because this path approach was motivated from upstream() revsets which I was trying to get rid off. And I like your 'path:' idea too. Thanks!

pulkit edited the summary of this revision. (Show Details)Jul 28 2018, 4:45 PM
pulkit retitled this revision from remotenames: add paths argument to remotenames revset to remotenames: add names argument to remotenames revset.
pulkit updated this revision to Diff 9669.
yuja added a comment.Aug 3 2018, 10:17 AM

+@revsetpredicate('remotebranches([name, ...])')

Can you start with a single "name" argument?

It doesn't make sense that remotebranches() accepts many OR patterns but
branch() doesn't.

In D3639#63068, @yuja wrote:

+@revsetpredicate('remotebranches([name, ...])')

Can you start with a single "name" argument?
It doesn't make sense that remotebranches() accepts many OR patterns but
branch() doesn't.

I concur - if you can pass a regex (which you can), that's fine for my use case, let's see how far that gets us.

This revision was automatically updated to reflect the committed changes.