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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jens Lehmann <Jens.Lehmann@xxxxxx> writes:

> Maybe the subject should rather be:
> "submodule: document failures handling relative superproject origin URLs"
>
> 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).

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.

>> Signed-off-by: Jon Seymour <jon.seymour@xxxxxxxxx>
>> ---
>>  t/t7400-submodule-basic.sh | 62 +++++++++++++++++++++++++++++++++++++++++++++
>>  t/t7403-submodule-sync.sh  | 63 +++++++++++++++++++++++++++++++++++++++++++++-
>>  2 files changed, 124 insertions(+), 1 deletion(-)
>> 
>> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
>> index 81827e6..97e7a73 100755
>> --- a/t/t7400-submodule-basic.sh
>> +++ b/t/t7400-submodule-basic.sh
>> @@ -507,6 +507,68 @@ test_expect_success 'relative path works with user@host:path' '
>>  	)
>>  '
>
> But please use test_expect_failure for all tests that fail due to
> current bugs and document what should succeed in the commands used
> inside the test case (just like you did in v3). The only change
> needed when the bug is fixed should be changing each
> test_expect_failure to test_expect_success.

Very true.

Thanks for a review.

--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]