[Bug 5233] New: Revision numbers can conflict with nodeids, which is surprising if revision numbers are hidden

mercurial-bugs at selenic.com mercurial-bugs at selenic.com
Tue May 10 22:53:53 UTC 2016


https://bz.mercurial-scm.org/show_bug.cgi?id=5233

            Bug ID: 5233
           Summary: Revision numbers can conflict with nodeids, which is
                    surprising if revision numbers are hidden
           Product: Mercurial
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: feature
          Priority: wish
         Component: Mercurial
          Assignee: bugzilla at selenic.com
          Reporter: hg at pewpew.net
                CC: mercurial-devel at selenic.com

Summary: Make a configuration option to make `hg co 1` and `hg co 'id(1)'`
synonymous; if one wants revision 1 they can use `hg co 'rev(1)'`.

Details:
If I have a repo that looks like this, and a log format that does NOT include
revision numbers:
> hg log -G -T'{shortest(node, 8)} {author|user} {tags}\n{desc}' 
@  5559972b user tip
|  third
o  678901cc user
|  Second
o  121c92e4 user
   Random data to make hash start with 1: 5

Things get a bit weird to the external observer:
> hg co 6
> hg log -G -T'{shortest(node, 8)} {author|user} {tags}\n{desc}'
o  5559972b user tip
|  third
@  678901cc user
|  Second
o  121c92e4 user
   Random data to make hash start with 1: 5


"Cool, looks like I can just specify the shortest non-ambiguous!"
> hg co 5
> hg log -G -T'{shortest(node, 8)} {author|user} {tags}\n{desc}'
@  5559972b user tip
|  third
o  678901cc user
|  Second
o  121c92e4 user
   Random data to make hash start with 1: 5

"yay, it works, I understand everything!"
> hg co 1
> hg log -G -T'{shortest(node, 8)} {author|user} {tags}\n{desc}'
o  5559972b user tip
|  third
@  678901cc user
|  Second
o  121c92e4 user
   Random data to make hash start with 1: 5

Wat.  ಠ_ಠ  I said 1, it should be on the 'Random data' one, not 'Second'!  It's
not ambiguous!  *files bug*.


The problem is that revision numbers are looked at first, and then nodeids are
considered.  This is essentially a requirement in any repo that expects to use
revision numbers: if it were any other way, revision numbers would never work,
because it's very likely there's a nodeid out there that starts with your
revision number.  But, if the user (or the people managing the deployment at
the company ;)) explicitly are not showing revision numbers to users, this is
really confusing behavior.

It would be nice if there was an option to disable revision numbers from the
default overload resolution and instead require them to be explicitly
specified, so that `hg co 5` looks ONLY at nodeids, and you can explicitly
state you want to use a revision number using revset syntax:
> hg co 'rev(1)'
> hg log -G -T'{shortest(node, 8)} {author|user} {tags}\n{desc}'
o  5559972b user tip
|  third
@  678901cc user
|  Second
o  121c92e4 user
   Random data to make hash start with 1: 5

> hg co 'rev(5)'
abort: empty revision set



More details:
> hg version
Mercurial Distributed SCM (version 3.8-rc+31-38292b227deb)
(see https://mercurial-scm.org for more information)

Copyright (C) 2005-2016 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



Re-create that repo:
> hg init
> echo a > foo
> hg ci -u 'user at example.com' -d '0 0' -Am 'Random data to make hash start with 1: 5'
adding foo
> echo b > foo
> hg ci -u 'user at example.com' -d '0 0' -Am 'Second'
> echo c > foo
> hg ci -u 'user at example.com' -d '0 0' -Am 'third'

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Mercurial-devel mailing list