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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 23.05.2012 23:14, schrieb Junio C Hamano:
> 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.