git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v2] submodule add: improve message when resolving a relative url fails

From
Jens Lehmann <jens.lehmann@web.de>
Date
May 31, 2011, 21:34 UTC
Message-ID
<4DE55EF7.9050609@web.de>
In-Reply-To
<4DE5561C.3010200@xiplink.com>
A "git submodule add ../sub" interprets "../sub" relative to the default
remote of the superproject. To be able to do that, a url for that remote
has to be set in the superproject's .git/config. If that is not the case
the command fails with:
	"remote (origin) does not have a url defined in .git/config"

This neither mentions the relative repository nor that the .git/config of the superproject is the one with the missing url. And as a novice user could assume that relative paths would work just like absolute paths do in the filesystem and run into this by accident, the message is not very helpful.

So change that to
	Cannot resolve "../sub" relative to this repository's "origin"
	remote: The remote's URL is not set in .git/config
to give the user a clue that "git submodule add" interprets a relative
path as being relative to its default remote, not the work tree.
Thanks-to: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Thanks for your review, here is the updated patch.
Am 31.05.2011 22:57, schrieb Marc Branchaud:
Show 13 quoted lines
> However, overall I think this is a pretty fragile way to handle relative
> paths.  Consider:
> 
>  - The super-repo must be a clone in order for this to work at all.
> 
>  - The super-repo cannot be checked out on a detached HEAD.
> 
>  - The current code rewrites the URL so that any relative path is either
>    rejected or munged into an absolute remote URL.
> 
> It seems to me that this feature will only work in a fairly narrow set of
> circumstances, and even when it does work it's likely to do something
> unexpected (think of a super-repo with several remotes).

And even worse: it defies the principle of least surprise when I can't just replace an absolute filesystem path with a relative one just like almost everywhere else ... an option enabling this behavior might have been a better way in hindsight.

Show 5 quoted lines
> Back when Junio accepted the original patch, he said "If you maintain and
> serve a set related projects you need to give the users a single URL (per
> where the user is and how to reach the server)."  I'm not sure I understand
> that:  Why would the users be adding their own submodules to the
> superproject?  Wouldn't the superproject define the submodules in for them?

I can't tell about that reasoning, but it might make sense in a way I don't understand yet ...

> I think it would be better to either just reject relative paths entirely, or
> accept any relative path as-is and display a warning that the submodule is
> only valid on the local machine.  (Perhaps one day receive-pack could even be
> taught to reject any pushes with a .gitmodules file containing a relative URL.)

Breaking backwards compatibility should not be considered easily. I tend to not change such things until I understand the use cases for the solution, especially as submodule use cases tend to be very different ...

 git-submodule.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index d189a24..587d74e 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -34,7 +34,7 @@ resolve_relative_url ()
 {
 	remote=$(get_default_remote)
 	remoteurl=$(git config "remote.$remote.url") ||
-		die "remote ($remote) does not have a url defined in .git/config"
+		die "Cannot resolve \"$1\" relative to this repository's \"$remote\" remote: The remote's URL is not set in .git/config"
 	url="$1"
 	remoteurl=${remoteurl%/}
 	sep=/

-- 
1.7.5.3.445.g9c0c23
Previous: Marc BranchaudNext: Phil Hord
Message 7 of 40 in “Tests for some submodule corner cases.”
  1. 0/2 Tests for some submodule corner cases.Marc Branchaud, May 30, 2011
  2. 1/2 Added a test for "submodule add" using a ../relative/path/to/the/submodule/repoMarc Branchaud, May 30, 2011
  3. 2/2 Added a test for "submodule status" when the submodule's working directory has deleted files.Marc Branchaud, May 30, 2011
  4. Jens LehmannMay 31, 2011
  5. submodule add: improve message when resolving a relative url failsJens Lehmann, May 31, 2011
  6. Marc BranchaudMay 31, 2011
  7. submodule add: improve message when resolving a relative url failsJens Lehmann, May 31, 2011
  8. Phil HordMay 31, 2011
  9. Marc BranchaudJun 1, 2011
  10. Phil HordJul 27, 2011
  11. Marc BranchaudJul 29, 2011
  12. Junio C HamanoMay 31, 2011
  13. Clarified how "git submodule add" handles relative paths.Marc Branchaud, Jun 1, 2011
  14. Junio C HamanoJun 1, 2011
  15. Jens LehmannJun 1, 2011
  16. Junio C HamanoJun 2, 2011
  17. Jens LehmannJun 3, 2011
  18. Junio C HamanoJun 3, 2011
  19. Mark LevedahlJun 4, 2011
  20. Jens LehmannJun 4, 2011
  21. Jens LehmannJun 4, 2011
  22. Junio C HamanoJun 5, 2011
  23. 0/3 submodule add: allow relative repository path even when no url is setJens Lehmann, Jun 6, 2011
  24. 1/3 submodule add: test failure when url is not configured in superprojectJens Lehmann, Jun 6, 2011
  25. 2/3 submodule add: allow relative repository path even when no url is setJens Lehmann, Jun 6, 2011
  26. 0/2 Improve "git submodule add" documentation.Marc Branchaud, Jun 6, 2011
  27. 1/2 More precisely described how "git submodule add" handles relative submodule URLs.Marc Branchaud, Jun 6, 2011
  28. 2/2 Moved paragraph describing the utility of relative submodule URLs.Marc Branchaud, Jun 6, 2011
  29. 3/3 submodule add: clean up duplicated codeJens Lehmann, Jun 6, 2011
  30. Junio C HamanoJun 6, 2011
  31. Marc BranchaudJun 6, 2011
  32. Jens LehmannJun 6, 2011
  33. Jens LehmannJun 7, 2011
  34. Phil HordJun 8, 2011
  35. [PATCHv2] Clarified how "git submodule add" handles relative paths.Marc Branchaud, Jun 2, 2011
  36. Marc BranchaudMay 31, 2011
  37. Jens LehmannMay 31, 2011
  38. Marc BranchaudJun 1, 2011
  39. Junio C HamanoJun 1, 2011
  40. Jens LehmannJun 1, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.