Mercurial seems to get confused in this situation: I have a repo with a few branches: wolf@hp:~/dev/py/unittest2$ hg branches default 429:ba7ee7f6aa37 plugins 412:d626ef45b357 python2.3 251:8beb2ea7d0be I create a clone with the same name of one of the branches (e.g. plugins): wolf@hp:~/dev/py/unittest2$ cd .. wolf@hp:~/dev/py$ hg clone unittest2 plugins updating to branch default 38 files updated, 0 files merged, 0 files removed, 0 files unresolved *Without* moving in the new clone, I do "hg up plugins" and Mercurial changes branch to 'plugins' inside the 'plugins' dir: wolf@hp:~/dev/py$ hg up plugins 49 files updated, 0 files merged, 0 files removed, 0 files unresolved wolf@hp:~/dev/py$ cd plugins/ wolf@hp:~/dev/py/plugins$ hg branch plugins This doesn't work when there's no dir with the given name: wolf@hp:~/dev/py$ hg up default abort: There is no Mercurial repository here (.hg not found)! Or when there's a dir with the given name, but that doesn't have a branch with the same: wolf@hp:~/dev/py$ hg up unittest2 abort: unknown revision 'unittest2'! I would expect this to give the "abort: There is no Mercurial repository here (.hg not found)!" error in both the cases instead. I noticed this because I usually keep a dir for each branch (with the same name), and when I create a new clone and do hg up <branch> to change branch forgetting to cd in the dir, I get "0 files updated, 0 files merged, 0 files removed, 0 files unresolved" because it's trying to update the dir 'branch' to the branch 'branch'.
Confirmed: $ hg init plugins $ cd plugins $ hg tag 0 -m0 $ hg branch plugins marked working directory as branch plugins $ hg tag 1 -m1 $ hg branch python2.3 marked working directory as branch python2.3 $ hg tag 2 -m2 $ hg sum parent: 2:b6c00ad14543 tip 2 branch: python2.3 commit: (clean) update: (current) $ cd .. $ hg up plugins 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R plugins sum parent: 1:27fb7e0eb35d 2 1 branch: plugins commit: (clean) update: (current) The problem is that the update command really is invalid because there is no hg repo in the working directory and no repo is specified with -R. Mercurial is however "helpful" and tries to guess what the user might have meant, notices that the user might refer to the 'plugins' repo, and uses that. http://www.selenic.com/hg/file/0995eee8ffe4/mercurial/dispatch.py#l583 If there is an outside repo the update will correctly fail: $ hg init . $ hg up plugins abort: unknown revision 'plugins'! [255] I think it is unfortunate that Mercurial tries to guess by assuming that unknown parameters might specify a repo to use. If it is in doubt it would be better if aborted and told the user to use -R. A better solution would be if commands that do take file names as parameters could all be made 'optionalrepo' and deduce the repo to use by looking at the specified filenames. If a repo already was known (from cwd or -R) it should keep complaining as it does now if the files were inside another repo: $ hg log plugins/foo abort: path 'plugins/foo' is inside repo 'plugins' [255]
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:19 EDT --- This bug was previously known as _bug_ 2748 at http://mercurial.selenic.com/bts/issue2748
Agreed that this behaviour is strange.
We could limit the commands that dispatch attempts to infer repos on to ones that take files as arguments.
Fixed by http://selenic.com/repo/hg/rev/434e5bd615fc Siddharth Agarwal <sid0@fb.com> commands: don't infer repo for commands like update (issue2748) Maintain a whitelist of commands to infer the repo for instead. The whitelist contains those commands that take file(s) in the working dir as arguments. (please test the fix)