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

[Jon Seymour <jon.seymour@xxxxxxxxx>]

On Sun, May 20, 2012 at 4:56 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote:
> Am 19.05.2012 06:40, schrieb Jon Seymour:
>
> Just a small nit: I'd prefer to replace the 4 occurrences of the term
> "supermodule" with "superproject".

Sure. I can't argue with precedent, of course, but I guess I was
favouring the consistency in the suffixes used with sub and super.

>
>
> BTW, what happened to the following comment in you other email?
>
>>> +                               remoteurl="${up_path%/}/${remoteurl%/*}"
>>
>> Meant up_path%/ to be up_path%/*
>
> The '*' is not there (but the test suite runs fine no matter if I add
> a '*' there or not). Thinking about it not adding the '*' should be
> correct, as you just want to chop off a trailing '/' from $up_path
> here, right?

Yes %/* was actually the wrong thing to do - my original intent was to
remove repeated trailing occurrences of /, but, of course, %/* doesn't
do that, nor should it be necessary  (assuming the sm_path was
normalized during add).

>
> So no objection on the code changes from my side.

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.

jon.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html