[PATCH RFC] revset: use '%' as an operator for 'only'

Martin von Zweigbergk martinvonz at google.com
Tue Nov 11 11:28:49 CST 2014


On Mon Nov 10 2014 at 5:06:36 PM Matt Mackall <mpm at selenic.com> wrote:

> On Thu, 2014-11-06 at 22:40 -0800, Sean Farley wrote:
> > Martin von Zweigbergk writes:
> >
> > > On Thu Nov 06 2014 at 2:57:01 PM Sean Farley <
> sean.michael.farley at gmail.com>
> > > wrote:
> > >
> > >> # HG changeset patch
> > >> # User Sean Farley <sean.michael.farley at gmail.com>
> > >> # Date 1415314518 28800
> > >> #      Thu Nov 06 14:55:18 2014 -0800
> > >> # Node ID 752f70bee3b0542ca36b1fecbb70c954d6017061
> > >> # Parent  2d54aa5397cdb1c697673ba10b7618d5ac25c69e
> > >> revset: use '%' as an operator for 'only'
> > >>
> > >> With this patch, we can make it much easier to specify 'only(A,B)' ->
> > >> A%B. Similarly, 'only(A)' -> A%.
> > >>
> > >
> > > That would let me send patches with 'hg email -r .%@'. Should the first
> > > argument default to '.' so it's just '%@'?
> >
> > That's not a bad idea. I'll try implementing that.
>
> I think in most cases '.%' would suffice, right? "Everything on . that's
> not descended from another head". To get in trouble, you'd need a
> topology like this:
>
> o-o-o-o <-@
>  \
>   a-c <- foo
>    \
>     b <- .
>
> .% = only a
> .%@ = a and b
>

I actually do end up in this scenario quite frequently. Usually it's
because I realize that 'c' was not the right way of doing foo and I try
something else out. I may then histedit 'a' and 'b' a bit until I'm happy
and I decide that foo should point to the new version of 'b'. It's usually
for histedit and log that I use 'only(.,@)'. So at least in my case, it's
more likely that the first argument is '.' than the second one being the
implicit 'any'.

Anyway, as I said to Pierre-Yves, I think it's fine that the first argument
is mandatory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141111/4fc9e1d1/attachment.html>


More information about the Mercurial-devel mailing list