Re: [PATCH v4 1/2] submodule: document handling of relative superproject origin URLs
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 23, 2012, 21:14 UTC
- Message-ID
- <7vvcjmzjkv.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4FBD4F68.90305@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
Show 17 quoted lines
> 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.
Show 19 quoted lines
>> Signed-off-by: Jon Seymour <jon.seymour@gmail.com> >> --- >> 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.