[PATCH] subrepo: allow remapping subpaths using the "final" path
Martin Geisler
mg at aragost.com
Thu Sep 22 08:16:44 CDT 2011
Matt Mackall <mpm at selenic.com> writes:
> On Thu, 2011-08-11 at 09:33 +0200, Martin Geisler wrote:
>> 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?
>
> base = "src/foo"
> parent = "http://example.net/parent"
> full = join(parent, base)
> final = remap(full)
> if final == full: # no remapping, try old-style remapping
> final = join(parent, remap(base))
Okay -- great idea! I've finally reworked the patch and since it now
looks small and sweet I pushed it with this fallback.
--
Martin Geisler
aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/
More information about the Mercurial-devel
mailing list