[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