Re: [PATCH] Clarified how "git submodule add" handles relative paths.
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:21
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: [PATCH] Clarified how "git submodule add" handles relative paths. · Jens Lehmann <hidden>
- 2016-06-15 · Re: [PATCH] Clarified how "git submodule add" handles relative paths. · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH] Clarified how "git submodule add" handles relative paths. · Mark Levedahl <hidden>
- 2016-06-15 · Re: [PATCH] Clarified how "git submodule add" handles relative paths. · Jens Lehmann <hidden>
- 2016-06-15 · Re: [PATCH] Clarified how "git submodule add" handles relative paths. · Jens Lehmann <hidden>
Marc Branchaud [off-list ref] writes:
So this is really about saving the users the hassle of modifying all the URLs in the .gitmodules file. Does this patch document what you mean?
I do not necessarily think it is _solely_ about users. Another obvious example I left unsaid was what would happen when your project gets popular and gets mirrored to many places. Surely you need to advise people of alternate locations of the top-level, but what is recorded in .gitmodules will be relative to that top-level, so they do not have to be changed. Even if you have only one public repository, I would imagine that the same convenience would apply if you ever decide to switch the project hosting site. "Users can use a URL different from what was given by the maintainer" is merely an example; I doubt it deserves stressing that much.
quoted hunk
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 1a16ff6..54dfebb 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt@@ -77,8 +77,17 @@ to exist in the superproject. If <path> is not given, the + <repository> is the URL of the new submodule's origin repository. This may be either an absolute URL, or (if it begins with ./ -or ../), the location relative to the superproject's origin -repository. +or ../) a URL relative to one of the superproject's remote +repostories: If the superprojet's currently checked-out branch tracks +a remote branch then that remote's URL is used, otherwise the "origin" +remote's URL is used. Relative URLs allow users to easily clone the +superproject and its submodules using a different URL than what the +superproject's maintainer might use (e.g. the maintainer can use ssh:// +URLs while the users might use git:// URLs). With relative URLs in the +.gitmodules file, the users won't have to edit all the submodule URLs. ++ +*NOTE*: This means that you can *not* use a relative path to refer to a +repository in your local filesystem.
It is not "can not" but "do not", is it? More importantly, I do not think it is limited to the case of relative path at all. I thought that in general "submodule add" takes a URL and never a _local_ filesystem location, as the whole point [*1*] of running "submodule add" command is to update the entry in the .gitmodules file for people who may not have access to _your_ local filesystem in the first place? I am starting to suspect that the original confusion that started this thread is coming from misunderstanding in this area. [Footnote] *1* The command also adds a corresponding entry to your own .git/config file so that you can work as if you are just one of your users and as if you did "submodule init" based on what is in .gitmodules.