[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