Re: [PATCH 2/2] submodule: fix handling of supermodules with relative origin URLs
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- May 20, 2012, 00:34 UTC
- Message-ID
- <4FB83BFC.4000702@web.de>
- In-Reply-To
- <CAH3AnrrqiXqdHHGZPyOPJ3Zend5JrQX0rKV+pz_mjs3SDjv9DA@mail.gmail.com>
Am 20.05.2012 00:51, schrieb Jon Seymour:
Show 8 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: >> >> 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.
No big deal, but in recent posts "superproject" has been used and the similarity between "supermodule" and "submodule" fooled me when I read your RFC patch. So even though a superproject might be the a submodule of another superproject, I'm all for using the term "superproject" to make the distinction obvious.
Show 10 quoted lines
>> 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.
Me thinks that this is subject for a subsequent patch. Having the URL of the superproject *below* the root directory of the superproject seems like a rather odd case which warrants a fix of its own ;-)