Subrepository remapping plan

Martin Geisler mg at
Mon Aug 9 09:30:36 CDT 2010

Kevin Bullock <kbullock+mercurial at> writes:

> On 23 Jul 2010, at 8:44 AM, Martin Geisler wrote:
>> Dirkjan Ochtman <dirkjan at> writes:
>>> On Fri, Jul 23, 2010 at 13:38, Martin Geisler <mg at> wrote:
>>> - Why do we need the intermediate key "libfoo"? It seems like we could
>>> just use the in-repo path to the subrepo to key off of (i.e. the
>>> subpaths file or hgrc would have lib/foo =
>>> It might change location in
>>> the repo, but it wouldn't be hard to add an extra mapping entry (the
>>> libfoo is also prone to being renamed at some point).
>> Ah, that idea is new. The original idea was to solve the problem of
>> outdated URLs, and this is why I propose we remap URLs (= right-hand
>> sides in the .hgsub file).
>> If we base the remapping on the left-hand sides instead, then we base it
>> on something which can already change today, but something which causes
>> no problems when it change. The problem is changing right-hand sides.
> What about, instead of using the extra level of indirection, remap the
> URLs directly, like so:
> # .hg/subpaths

That is actually what I propose. The wiki page only mentions it briefly,
when it says:

  This mechanism can also be used by people who have hard coded paths
  and now need to remap them because of repository reorganization.

The symbolic names used in the right-hand sides in the .hgsub file need
not be short identifiers like 'libfoo' in the Wiki page -- they can also
be full URLs.

> Also, what about extending the concept of this to allow the user to
> override any subrepo path in their hgrc, without pushing those
> mappings? Sort of like localtags?

That is also in the proposal :-) The remapping is done by first reading
the .hg/subpaths file, and then reading the normal configuration files
such as the .hg/hgrc file. This lets the user override the remapping as

Martin Geisler

aragost Trifork
Professional Mercurial support

More information about the Mercurial-devel mailing list