Re: [PATCH v4 1/2] submodule: document handling of relative superproject origin URLs

From: Jens Lehmann <jens.lehmann@web.de>
Date: May 23, 2012, 21:45 UTC
Message-ID: <4FBD5A61.1030101@web.de>
In-Reply-To: <7vvcjmzjkv.fsf@alter.siamese.dyndns.org>

Am 23.05.2012 23:14, schrieb Junio C Hamano:

Show 25 quoted lines

> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> Am 23.05.2012 18:45, schrieb Jon Seymour:
>>> These tests document how submodule sync and init handle various
>>> kinds of relative super project origin URLs.  The submodule URL
>>> path is ../subrepo.
>>>
>>> 6 cases are documented:
>>>   foo
>>>   foo/bar
>>>   ./foo
>>>   ./foo/bar
>>>   ../foo
>>>   ../foo/bar
>>
>> Nice test coverage!
> 
> I recall correctly, the original use case for relative URL entries in the
> .gitmodules file (to be copied to .git/config as submodule.$name.path) was
> so that by looking at the top-level, the locations of the origins for
> submodule repositories can be known from where the top-level was cloned.
> The above cases do not seem to be relevant, so in the sense, they are of
> secondary importance (and I do not find the "sneakernet tool" example
> convincing---the sneakernet tool that is distributed in the scenario can
> be written differently so that it does not require the other repositories
> to be named relative to it).

Remember this patch series is not about relative /submodule/ urls but relative /superproject/ urls, so the .gitmodules file is not involved here. But while reviewing 2/2 I started to suspect I was a bit too hasty judging the coverage, as I realized only "git submodule init" and "git submodule sync" are tested. "git submodule add" should also be tested here to make sure it behaves well too (and only when the tests cases are not split across two commits they can be properly reviewed). My remark aimed at the attempt to test all possible relative paths in at least two depths, which I deem very helpful to find problems early.

> As long as you and submodule stakeholders believe this is a reasonable
> addition and does not break the existing use cases, I am perfectly fine
> with it, though.

Me thinks relative /superproject/ urls starting with ./ or ../ should work just fine (which they don't right now). And if relative superproject urls inside the superproject are handled too without too much hassle I won't argue against it, even though I'm not convinced of the use case either.