Bug 2748 - "hg up x" works from the parent dir when the dir 'x' has an 'x' branch
Summary: "hg up x" works from the parent dir when the dir 'x' has an 'x' branch
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-02 12:12 UTC by Ezio Melotti
Modified: 2012-10-26 13:30 UTC (History)
5 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ezio Melotti 2011-04-02 12:12 UTC
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'.
Comment 1 kiilerix 2011-04-02 18:55 UTC
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]
Comment 2 Bugzilla 2012-05-12 09:19 UTC
--- 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
Comment 3 Bryan O'Sullivan 2012-09-21 18:19 UTC
Agreed that this behaviour is strange.
Comment 4 Matt Mackall 2012-09-21 18:24 UTC
We could limit the commands that dispatch attempts to infer repos on to ones that take files as arguments.
Comment 5 HG Bot 2012-10-16 16:12 UTC
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)