On Wed, 11 Apr 2018 11:36:05 +0200, Feld Boris wrote: > >> The proposal here is to define a prefix for which we break backward > >> compatibility. If we do so, people with a "<set>" label will have to use: > >> > >> "<set>":whatever > >> > >> to get a similar effect. > > IIRC x:y was the most important syntax that needed a strong BC guarantee, so > > this proposal doesn't sound good. > > Indeed, the `x:y` is important and we don't want to break the BC > guarantee of it. > > The proposal is less impacting, only people using 'set' as labels and > using it at the beginning of a revsetwould be impacted. This prefix has > the advantage of being concise and coherent with whatfilesetuse.
Doesn't '-r set:foo' look like a range? I don't like an idea of introducing another ambiguous syntax to resolve ambiguity, but furthermore "set:foo" seems confusing to humans. IIUC, we have "set:" for filesets only because that's the syntax to specify file patterns. If we really want to add something to force revset evaluation, I think it has to be compatible with the current syntax, such as "(EXPR)" or "revset(EXPR)". > > Since "foo(bar)" needs quotes in revset query (except for x and x:y), it > > would > > makes some sense to add an option to disable the compatibility hack at all. > > We cannot see a way to make the config option both easily discoverable > and constrained. There is lot of labels that includes `-`, `+` and other > symbols that will be impacted. sigh. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
