lookup() seems to be about looking up a revision based on a symbol
that may come from the user (via the wire protocol), so revsymbol() is
appropriate here.
Details
- Reviewers
indygreg - Group Reviewers
hg-reviewers - Commits
- rHG0a1fb171dc1d: localrepo: use revsymbol() in lookup()
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
scmutil.revsymbol() just calls repo[x]. So what is your intention here?
FWIW, we must preserve repo.lookup('0') resolving to revision 0 because share.poolnaming=identity relies on it.
See D3024, including the discussion with Yuya there. In short, revsymbol will gradually take over responsibility from changectx.__init__ for interpreting strings.
FWIW, we must preserve repo.lookup('0') resolving to revision 0 because share.poolnaming=identity relies on it.
That will continue to work, since '0' is a string.
Also, lookup() is part of the peer interface (i.e. how remote consumers are supposed to interact with the repo instance). They are supposed to call repo.peer() to get a localpeer() instance that exposes just the peer interface.
It /should/ be acceptable to remove all the peer interface members from localrepository and require everyone go through peer(). This includes known(), pushkey(), branchmap(), etc. That would mean localpeer would have to access private attributes of localrepository. That should be fine: the classes are in the same module. It would make monkeypatching from extensions a little bit more complicated. But it would still be possible.