[PATCH] subrepo: allow remapping subpaths using the "final" path

Martin Geisler mg at aragost.com
Thu Aug 11 02:33:24 CDT 2011


Matt Mackall <mpm at selenic.com> writes:

> On Wed, 2011-08-10 at 16:59 +0200, Martin Geisler wrote:
>> # HG changeset patch
>> # User Martin Geisler <mg at aragost.com>
>> # Date 1312988370 -7200
>> # Node ID 4cfdb06e702888cbd4cbe97cf0aec0cb01368456
>> # Parent  0cb27eda3a1e0ea47a9a0bd5d44f5d21ec4509e1
>> subrepo: allow remapping subpaths using the "final" path
>> 
>> The way subpath remapping happens now, the right-hand side of a .hgsub
>> entry is used, as is, to match the left-hand side of a subpaths entry.
>> The new idea is to expand the .hgsub entry by prefixing the parent
>> repo path *before* the match occurs - i.e. to operate on the final
>> path including the parent. For example,
>> 
>>   .hgsub entry:     src/foo = src/foo
>>   parent repo path: http://example.net/parent
>>   expansion:        http://example.net/parent/src/foo
>
> Ok, so before we'd try remapping src/foo, now with this option
> enabled, we'll try remapping the whole URL.

Yes, that is correct.

The advantage is that a rewriting rule like 'http:// = ssh://' now also
affects a trivial subrepo path like the above since we rewrite the
expansion instead of just 'src/foo'.

> Seems to me that it should be sufficiently safe to try both and avoid
> a confusing new option.

I'm not sure what "trying both" means here?

>> A new option named ui.subpaths-remapping controls this. It has two
>> values so far:
>> 
>> * "use-intermediate-path", which is the old behavior that applies the
>>   remapping rules before the expansion with the parent path occurs.
>>   This is the default.
>> 
>> * "use-final-path", which triggers the new behavior.
>
> Eek! It's bad enough that we can't choose between 'foobar' and
> 'foo_bar' naming. Also, this should probably just be a bool.

I would also prefer to avoid a new option for this and just turn on the
behavior by default. Mads also suggested that, so let me send a followup
patch with that so that we can discuss this smaller change.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/


More information about the Mercurial-devel mailing list