Re: [PATCH 2/2] submodule: fix handling of supermodules with relative origin URLs

From: Jon Seymour <jon.seymour@gmail.com>
Date: May 19, 2012, 23:10 UTC
Message-ID: <CAH3AnrrxgT1OQe-K2A91XfMLSd2WGvJ5CzyNR4tRqvYfp4wgQg@mail.gmail.com>
In-Reply-To: <CAH3AnrrqiXqdHHGZPyOPJ3Zend5JrQX0rKV+pz_mjs3SDjv9DA@mail.gmail.com>

On Sun, May 20, 2012 at 8:51 AM, Jon Seymour <jon.seymour@gmail.com> wrote:

Show 10 quoted lines

> On Sun, May 20, 2012 at 4:56 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 19.05.2012 06:40, schrieb Jon Seymour:
> I noticed one relative case that is not handled properly yet, but
> there is a workaround. If the superproject's origin URL is of the
> form: foo/bar (a case I actually have myself for reasons I can explain
> if you want me to), then the correct rule doesn't get matched by
> .*/*). The workaround is for the user to change foo/bar style origin
> URLs to ./foo/bar.
>
> Let me know if I should fix this case now too.

I think this expression:

    remoteurl=$(echo "remoteurl" | sed "s|^[^/][^:]*\$|./&|" )
    remoteurl=${remoteurl%/}

would normalize remoteurl correctly for the foo/bar case and not any other.

I'd also need to add at least one new test (or do I actually need 3?), of course.

jon.