[PATCH 5 of 9] revset: abort the query when there is no revision for "rev()" (BC)

Matt Mackall mpm at selenic.com
Tue Mar 31 07:42:42 CDT 2015


On Tue, 2015-03-31 at 08:38 -0400, Augie Fackler wrote:
> On Tue, Mar 31, 2015 at 8:08 AM, Matt Mackall <mpm at selenic.com> wrote:
> > On Mon, 2015-03-30 at 14:19 -0400, Augie Fackler wrote:
> >> On Tue, Mar 31, 2015 at 01:31:52AM +0900, FUJIWARA Katsunori wrote:
> >> > At Mon, 30 Mar 2015 14:05:45 +0900,
> >> > Yuya Nishihara wrote:
> >> > >
> >> > > On Mon, 30 Mar 2015 03:34:27 +0900, FUJIWARA Katsunori wrote:
> >> > > > # HG changeset patch
> >> > > > # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> >> > > > # Date 1427653752 -32400
> >> > > > #      Mon Mar 30 03:29:12 2015 +0900
> >> > > > # Node ID f9e9783d4f10af2974d77dbfaacd217f24fd3035
> >> > > > # Parent  efa05b47238ba2a0bca69cd40b8e2e1aed3a2cf2
> >> > > > revset: abort the query when there is no revision for "rev()" (BC)
> >> > > >
> >> > > > Before this patch, "REV" and "rev(REV)" differ from each other:
> >> > > >
> >> > > >     target      REV          rev(REV)
> >> > > >     ----------- ------------ ------------
> >> > > >     known       pass         pass
> >> > > >     hidden      abort (*1)   pass (=> empty set)
> >> > > >     unknown     abort        pass (=> empty set)
> >> > > >
> >> > > >     (*1) abort with "use --hidden" hint
> >> > > >
> >> > > > For equivalence between them, "rev(REV)" should abort the query for
> >> > > > hidden or unknown revisions, even though this may break backward
> >> > > > compatibility for existing tools, which expect that "rev()" doesn't
> >> > > > abort the query in any cases.
> >> > >
> >> > > I thought about it before, but because rev() didn't raise error for 3 years,
> >> > > I'm afraid that there would be some tools that rely on the existing behavior.
> >> >
> >> > What about introducing new predicates "revnum()" (and "hashid()") or
> >> > so for strict behavior ? (should we make "rev()"/"id()" deprecate, too ?)
> >>
> >> I'd be in favor of something like that iff we can't declare the
> >> no-args behavior of rev() and id() to be bugs, which would be my
> >> strong preference. cc'ing mpm so he can weigh in.
> >
> > "no-args behavior"?
> 
> I worded things poorly, but also completely misread the table above. I
> had (wrongly) thought this was making it so that no-arguments-passed
> rev() and id() would be saner by returning errors, but it's actually
> about an argument being passed that's somehow invalid being allowed to
> slip by.
> 
> I'm no longer a fan of where this series is going, both because it
> seems wrong and because I can't fathom a usecase.
> 
> >
> > We seem to be preparing to change the behavior with explicitly naming
> > hidden changesets, but no one wants to tell me about it.
> 
> Huh? (I'm legitimately confused here, but I also haven't read -devel
> since work yesterday. If there's some sort of plan about that, I'm
> unaware of it.)

There's work underway to make:

hg log -r <somethinghidden>

..just work without needing --hidden, since it was specified explicitly.
I've been lobbying for this for a while. So far the plan seems to only
be to work on hashes though.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list