[PATCH] init: expand configured paths

[Matt Mackall]

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:

[paths]
foo=someexistingrepo

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.