[PATCH] init: expand configured paths

Matt Mackall mpm at selenic.com
Sun Aug 15 13:22:41 CDT 2010

On Sat, 2010-08-14 at 17:42 +0200, Martin Geisler wrote:
> Mads Kiilerich <mads at kiilerich.com> writes:
> > # HG changeset patch
> > # User Mads Kiilerich <mads at kiilerich.com>
> > # Date 1281308426 -7200
> > # Node ID 374d15fead75dd0892d2cd665c7f6ab8b993ad91
> > # Parent  fc8dc1afd52f339dc8471ecbec29a50fb21566f2
> > init: expand configured paths
> >
> > Most commands expands configured paths when repositories are
> > specified. Clone also expands the destination path (even though it
> > doesn't contain a repository yet). This makes init do the same.
> I don't think this is a good idea. I see the paths as shortcuts for
> pushing and pulling (and thus also cloning) but not as something we
> should expand in other situations.
> Right now the argument to 'hg init' is a local path and I think it would
> be confusing if 'hg init crew' would try to initialize a repository
> somewhere else than in my current directory, but because I may have
> defined a 'crew = ...' path in my ~/.hgrc.

Interesting. It's perfectly reasonable to want to do:


And then at some point want to do:

  hg clone foo # fails, foo is down
  hg clone foo-mirror foo

Since clone $1 $2 is morally equivalent (ie ignoring local
optimizations) to:

  hg init $2
  cd $2
  hg pull $1

..I would say the behavior of init should not to be to expand $2.

Unfortunately, the above example won't actually work, because clone IS
expanding the target. Yuck.

When does it ever make sense to expand the target of a new repository
anyway? Why would anyone add such a repo to their [paths] before it's
even created?

But really, this all doesn't matter much: either way, people are going
to hit it just once per repo they put in their paths, probably
considerably less. The cost of consistency here is quite low.

Mathematics is the supreme nostalgia of our time.

More information about the Mercurial-devel mailing list