{"thread":{"id":"27505","subject":"[PATCH 0/2] Tests for some submodule corner cases.","startedAt":"2011-05-30T21:51:18Z","lastAt":"2011-07-29T20:10:04Z","messageCount":40,"participants":["Marc Branchaud","Jens Lehmann","Phil Hord","Junio C Hamano","Mark Levedahl"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"169031","messageId":"1306792280-12768-1-git-send-email-marcnarc@xiplink.com","threadId":"27505","inReplyTo":null,"subject":"[PATCH 0/2] Tests for some submodule corner cases.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-05-30T21:51:18Z","receivedAt":"2011-05-30T21:51:18Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Ran across some submodule behavior that seems wrong to me. I don't have the\nchops to fix the issues, so I thought I'd just point them out with some unit\ntests.\n\nPatch 1 tests the case where \"submodule add\" fails if the path to the\nsubmodule repo is relative (i.e. starts with \"../\"). This currently fails\nwith \"remote (origin) does not have a url defined in .git/config\". Maybe\nthere's a reason to fail? If so, a better error message would be appreciated.\n\nPatch 2 exposes an anomaly in \"submodule status\", which reports that a\nsubmodule is OK even though it has deleted files. \"git status\" inside\nthe submodule (and in the super-repo) both identify any deleted files, but\n\"submodule status\" doesn't prefix the submodule's HEAD SHA-ID with a \"+\".\n\n(ps. I didn't sign-off these two patches, since they're just failing unit\ntests. Should I sign-off on them?)\n\n\t\tM.\n"},{"id":"169033","messageId":"1306792280-12768-2-git-send-email-marcnarc@xiplink.com","threadId":"27505","inReplyTo":"1306792280-12768-1-git-send-email-marcnarc@xiplink.com","subject":"[PATCH 1/2] Added a test for \"submodule add\" using a ../relative/path/to/the/submodule/repo","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-05-30T21:51:19Z","receivedAt":"2011-05-30T21:51:19Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"---\n t/t7400-submodule-basic.sh | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex b2b26b7..bbcfc61 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -86,6 +86,13 @@ test_expect_success 'submodule add' '\n \ttest_cmp empty untracked\n '\n \n+test_expect_failure 'submodule add with relative path to submodule repo' '\n+\t(\n+\t\tcd addtest &&\n+\t\tgit submodule add ../.subrepo relative_subrepo_path\n+\t)\n+'\n+\n test_expect_success 'submodule add to .gitignored path fails' '\n \t(\n \t\tcd addtest-ignore &&\n-- \n1.7.5.3.686.g35b8\n"},{"id":"169032","messageId":"1306792280-12768-3-git-send-email-marcnarc@xiplink.com","threadId":"27505","inReplyTo":"1306792280-12768-1-git-send-email-marcnarc@xiplink.com","subject":"[PATCH 2/2] Added a test for \"submodule status\" when the submodule's working directory has deleted files.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-05-30T21:51:20Z","receivedAt":"2011-05-30T21:51:20Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"---\n t/t7400-submodule-basic.sh | 6 ++++++\n 1 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex bbcfc61..d321540 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -331,6 +331,12 @@ test_expect_success 'status should be \"up-to-date\" after update' '\n \tgrep \"^ $rev1\" list\n '\n \n+test_expect_failure 'status should be \"modified\" if working dir deleted' '\n+\trm -rf init/* &&\n+\tgit submodule status >list &&\n+\tgrep \"^+$rev1\" list\n+'\n+\n test_expect_success 'checkout superproject with subproject already present' '\n \tgit checkout initial &&\n \tgit checkout master\n-- \n1.7.5.3.686.g35b8\n"},{"id":"169072","messageId":"4DE541EC.7010202@web.de","threadId":"27505","inReplyTo":"1306792280-12768-1-git-send-email-marcnarc@xiplink.com","subject":"Re: [PATCH 0/2] Tests for some submodule corner cases.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-05-31T19:30:52Z","receivedAt":"2011-05-31T19:30:52Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 30.05.2011 23:51, schrieb Marc Branchaud:\n> Ran across some submodule behavior that seems wrong to me. I don't have the\n> chops to fix the issues, so I thought I'd just point them out with some unit\n> tests.\n\nThanks for bringing these issues to our attention this way, having a way\nto easily reproduce them is very much appreciated.\n\n> Patch 1 tests the case where \"submodule add\" fails if the path to the\n> submodule repo is relative (i.e. starts with \"../\"). This currently fails\n> with \"remote (origin) does not have a url defined in .git/config\". Maybe\n> there's a reason to fail? If so, a better error message would be appreciated.\n\nI stumbled across this behavior now and then too, but according to the\ncommit it added (f31a522a2d) it is intended that adding a relative path\nbehaves differently than using an absolute path (it resolves relative to\nthe superproject's origin, not the filesystem, and to be able to do that\nthe superproject's .git/config has to have an url defined for it). But\nyou are right about the error message, it really isn't that helpful ...\n\n> Patch 2 exposes an anomaly in \"submodule status\", which reports that a\n> submodule is OK even though it has deleted files. \"git status\" inside\n> the submodule (and in the super-repo) both identify any deleted files, but\n> \"submodule status\" doesn't prefix the submodule's HEAD SHA-ID with a \"+\".\n\nThat is documented behavior. \"git submodule status\" only cares about the\ncommit recorded in the superproject vs the HEAD in the submodule, work\ntree modifications are never shown by it.\n\nBut try a \"git status\" in the superproject, that will give you the following\noutput:\n#\tmodified: init (modified content)\n"},{"id":"169073","messageId":"4DE548C4.2010600@web.de","threadId":"27505","inReplyTo":"4DE541EC.7010202@web.de","subject":"[PATCH] submodule add: improve message when resolving a relative url fails","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-05-31T20:00:04Z","receivedAt":"2011-05-31T20:00:04Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"A \"git submodule add ../sub\" interprets \"../sub\" relative to the default\nremote of the superproject. To be able to do that, a url for that remote\nhas to be set in the superprojects .git/config. If that is not the case\nthe command fails with:\n\t\"remote (origin) does not have a url defined in .git/config\"\n\nThis neither mentions the relative repository nor that the .git/config of\nthe superproject is the one with the missing url. And as a novice user\ncould assume that relative paths would work just like absolute paths do\nin the filesystem and run into this by accident, the message is not very\nhelpful.\n\nSo change that to\n\t\"Cannot resolve \"../sub\" relative to remote (origin), its url\n\t is not set in .git/config\"\nto give the user a clue that \"git submodule add\" interprets a relative\npath as being relative to its default remote, not the work tree.\n\nSigned-off-by: Jens Lehmann \n---\n\nAm 31.05.2011 21:30, schrieb Jens Lehmann:\n> Am 30.05.2011 23:51, schrieb Marc Branchaud:\n>> Patch 1 tests the case where \"submodule add\" fails if the path to the\n>> submodule repo is relative (i.e. starts with \"../\"). This currently fails\n>> with \"remote (origin) does not have a url defined in .git/config\". Maybe\n>> there's a reason to fail? If so, a better error message would be appreciated.\n> \n> I stumbled across this behavior now and then too, but according to the\n> commit it added (f31a522a2d) it is intended that adding a relative path\n> behaves differently than using an absolute path (it resolves relative to\n> the superproject's origin, not the filesystem, and to be able to do that\n> the superproject's .git/config has to have an url defined for it). But\n> you are right about the error message, it really isn't that helpful ...\n\nWhat about this patch?\n\n\n git-submodule.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex d189a24..14ef1d4 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -34,7 +34,7 @@ resolve_relative_url ()\n {\n \tremote=$(get_default_remote)\n \tremoteurl=$(git config \"remote.$remote.url\") ||\n-\t\tdie \"remote ($remote) does not have a url defined in .git/config\"\n+\t\tdie \"Cannot resolve \\\"$1\\\" relative to remote ($remote), its url is not set in .git/config\"\n \turl=\"$1\"\n \tremoteurl=${remoteurl%/}\n \tsep=/\n-- \n1.7.5.3.412.gb2afd.dirty\n"},{"id":"169074","messageId":"4DE5561C.3010200@xiplink.com","threadId":"27505","inReplyTo":"4DE548C4.2010600@web.de","subject":"Re: [PATCH] submodule add: improve message when resolving a relative url fails","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-05-31T20:57:00Z","receivedAt":"2011-05-31T20:57:00Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-05-31 04:00 PM, Jens Lehmann wrote:\n> A \"git submodule add ../sub\" interprets \"../sub\" relative to the default\n> remote of the superproject. To be able to do that, a url for that remote\n> has to be set in the superprojects .git/config. If that is not the case\n\nNit: superprojects --> superproject's\n\n> the command fails with:\n> \t\"remote (origin) does not have a url defined in .git/config\"\n> \n> This neither mentions the relative repository nor that the .git/config of\n> the superproject is the one with the missing url. And as a novice user\n> could assume that relative paths would work just like absolute paths do\n> in the filesystem and run into this by accident, the message is not very\n> helpful.\n> \n> So change that to\n> \t\"Cannot resolve \"../sub\" relative to remote (origin), its url\n> \t is not set in .git/config\"\n> to give the user a clue that \"git submodule add\" interprets a relative\n> path as being relative to its default remote, not the work tree.\n\nThanks for the cogent explanation & patch. I think the message could be\nimproved a bit:\n\n\tCannot resolve \"../sub\" relative to this repository's \"origin\"\n\tremote: The remote's URL is not set in .git/config\n\nHowever, overall I think this is a pretty fragile way to handle relative\npaths. Consider:\n\n - The super-repo must be a clone in order for this to work at all.\n\n - The super-repo cannot be checked out on a detached HEAD.\n\n - The current code rewrites the URL so that any relative path is either\n rejected or munged into an absolute remote URL.\n\nIt seems to me that this feature will only work in a fairly narrow set of\ncircumstances, and even when it does work it's likely to do something\nunexpected (think of a super-repo with several remotes).\n\nBack when Junio accepted the original patch, he said \"If you maintain and\nserve a set related projects you need to give the users a single URL (per\nwhere the user is and how to reach the server).\" I'm not sure I understand\nthat: Why would the users be adding their own submodules to the\nsuperproject? Wouldn't the superproject define the submodules in for them?\n\nI think it would be better to either just reject relative paths entirely, or\naccept any relative path as-is and display a warning that the submodule is\nonly valid on the local machine. (Perhaps one day receive-pack could even be\ntaught to reject any pushes with a .gitmodules file containing a relative URL.)\n\n\t\tM.\n\n\n> Signed-off-by: Jens Lehmann \n> ---\n> \n> Am 31.05.2011 21:30, schrieb Jens Lehmann:\n>> Am 30.05.2011 23:51, schrieb Marc Branchaud:\n>>> Patch 1 tests the case where \"submodule add\" fails if the path to the\n>>> submodule repo is relative (i.e. starts with \"../\"). This currently fails\n>>> with \"remote (origin) does not have a url defined in .git/config\". Maybe\n>>> there's a reason to fail? If so, a better error message would be appreciated.\n>>\n>> I stumbled across this behavior now and then too, but according to the\n>> commit it added (f31a522a2d) it is intended that adding a relative path\n>> behaves differently than using an absolute path (it resolves relative to\n>> the superproject's origin, not the filesystem, and to be able to do that\n>> the superproject's .git/config has to have an url defined for it). But\n>> you are right about the error message, it really isn't that helpful ...\n> \n> What about this patch?\n> \n> \n> git-submodule.sh | 2 +-\n> 1 files changed, 1 insertions(+), 1 deletions(-)\n> \n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index d189a24..14ef1d4 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -34,7 +34,7 @@ resolve_relative_url ()\n> {\n> \tremote=$(get_default_remote)\n> \tremoteurl=$(git config \"remote.$remote.url\") ||\n> -\t\tdie \"remote ($remote) does not have a url defined in .git/config\"\n> +\t\tdie \"Cannot resolve \\\"$1\\\" relative to remote ($remote), its url is not set in .git/config\"\n> \turl=\"$1\"\n> \tremoteurl=${remoteurl%/}\n> \tsep=/\n"},{"id":"169075","messageId":"4DE55857.3090706@xiplink.com","threadId":"27505","inReplyTo":"4DE541EC.7010202@web.de","subject":"Re: [PATCH 0/2] Tests for some submodule corner cases.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-05-31T21:06:31Z","receivedAt":"2011-05-31T21:06:31Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-05-31 03:30 PM, Jens Lehmann wrote:\n> Am 30.05.2011 23:51, schrieb Marc Branchaud:\n>> Ran across some submodule behavior that seems wrong to me. I don't have the\n>> chops to fix the issues, so I thought I'd just point them out with some unit\n>> tests.\n> \n> Thanks for bringing these issues to our attention this way, having a way\n> to easily reproduce them is very much appreciated.\n> \n>> Patch 1 tests the case where \"submodule add\" fails if the path to the\n>> submodule repo is relative (i.e. starts with \"../\"). This currently fails\n>> with \"remote (origin) does not have a url defined in .git/config\". Maybe\n>> there's a reason to fail? If so, a better error message would be appreciated.\n> \n> I stumbled across this behavior now and then too, but according to the\n> commit it added (f31a522a2d) it is intended that adding a relative path\n> behaves differently than using an absolute path (it resolves relative to\n> the superproject's origin, not the filesystem, and to be able to do that\n> the superproject's .git/config has to have an url defined for it). But\n> you are right about the error message, it really isn't that helpful ...\n> \n>> Patch 2 exposes an anomaly in \"submodule status\", which reports that a\n>> submodule is OK even though it has deleted files. \"git status\" inside\n>> the submodule (and in the super-repo) both identify any deleted files, but\n>> \"submodule status\" doesn't prefix the submodule's HEAD SHA-ID with a \"+\".\n> \n> That is documented behavior. \"git submodule status\" only cares about the\n> commit recorded in the superproject vs the HEAD in the submodule, work\n> tree modifications are never shown by it.\n> \n> But try a \"git status\" in the superproject, that will give you the following\n> output:\n> #\tmodified: init (modified content)\n\nI understand. My apologies for not reading the man page closely enough.\n\nI know there's been a lot of recent work on making \"git status\"\nsubmodule-friendly, but would there be any interest in having another prefix\nfor submodule status to cover this case? Maybe ! could indicate that the\nsubmodule's HEAD is correct, but the working directory doesn't match it exactly.\n\n\t\tM.\n"},{"id":"169077","messageId":"4DE55D0F.1020905@web.de","threadId":"27505","inReplyTo":"4DE55857.3090706@xiplink.com","subject":"Re: [PATCH 0/2] Tests for some submodule corner cases.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-05-31T21:26:39Z","receivedAt":"2011-05-31T21:26:39Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 31.05.2011 23:06, schrieb Marc Branchaud:\n> On 11-05-31 03:30 PM, Jens Lehmann wrote:\n>> Am 30.05.2011 23:51, schrieb Marc Branchaud:\n>>> Patch 2 exposes an anomaly in \"submodule status\", which reports that a\n>>> submodule is OK even though it has deleted files. \"git status\" inside\n>>> the submodule (and in the super-repo) both identify any deleted files, but\n>>> \"submodule status\" doesn't prefix the submodule's HEAD SHA-ID with a \"+\".\n>>\n>> That is documented behavior. \"git submodule status\" only cares about the\n>> commit recorded in the superproject vs the HEAD in the submodule, work\n>> tree modifications are never shown by it.\n>>\n>> But try a \"git status\" in the superproject, that will give you the following\n>> output:\n>> #\tmodified: init (modified content)\n> \n> I understand. My apologies for not reading the man page closely enough.\n\nNo problem, maybe that's just an indication that a reference to \"git status\"\nbeing more capable of telling what is going on inside a submodule is missing\nto the man page for \"git submodule status\".\n\n> I know there's been a lot of recent work on making \"git status\"\n> submodule-friendly, but would there be any interest in having another prefix\n> for submodule status to cover this case? Maybe ! could indicate that the\n> submodule's HEAD is correct, but the working directory doesn't match it exactly.\n\nI'd rather leave \"git submodule status\" as it is and incorporate this kind\nof functionality into core git (for \"submodule status\" it already arrived there\nin 1.7.0/1.7.1, so that part is finished ;-). I hope making the \"git submodule\"\nscript mostly obsolete in the long run and would want to avoid teaching it new\nstuff already covered by core git.\n"},{"id":"169078","messageId":"4DE55EF7.9050609@web.de","threadId":"27505","inReplyTo":"4DE5561C.3010200@xiplink.com","subject":"[PATCH v2] submodule add: improve message when resolving a relative url fails","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-05-31T21:34:47Z","receivedAt":"2011-05-31T21:34:47Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"A \"git submodule add ../sub\" interprets \"../sub\" relative to the default\nremote of the superproject. To be able to do that, a url for that remote\nhas to be set in the superproject's .git/config. If that is not the case\nthe command fails with:\n\t\"remote (origin) does not have a url defined in .git/config\"\n\nThis neither mentions the relative repository nor that the .git/config of\nthe superproject is the one with the missing url. And as a novice user\ncould assume that relative paths would work just like absolute paths do\nin the filesystem and run into this by accident, the message is not very\nhelpful.\n\nSo change that to\n\tCannot resolve \"../sub\" relative to this repository's \"origin\"\n\tremote: The remote's URL is not set in .git/config\nto give the user a clue that \"git submodule add\" interprets a relative\npath as being relative to its default remote, not the work tree.\n\nThanks-to: Marc Branchaud \nSigned-off-by: Jens Lehmann \n---\n\nThanks for your review, here is the updated patch.\n\nAm 31.05.2011 22:57, schrieb Marc Branchaud:\n> However, overall I think this is a pretty fragile way to handle relative\n> paths. Consider:\n> \n> - The super-repo must be a clone in order for this to work at all.\n> \n> - The super-repo cannot be checked out on a detached HEAD.\n> \n> - The current code rewrites the URL so that any relative path is either\n> rejected or munged into an absolute remote URL.\n> \n> It seems to me that this feature will only work in a fairly narrow set of\n> circumstances, and even when it does work it's likely to do something\n> unexpected (think of a super-repo with several remotes).\n\nAnd even worse: it defies the principle of least surprise when I can't\njust replace an absolute filesystem path with a relative one just like\nalmost everywhere else ... an option enabling this behavior might have\nbeen a better way in hindsight.\n\n> Back when Junio accepted the original patch, he said \"If you maintain and\n> serve a set related projects you need to give the users a single URL (per\n> where the user is and how to reach the server).\" I'm not sure I understand\n> that: Why would the users be adding their own submodules to the\n> superproject? Wouldn't the superproject define the submodules in for them?\n\nI can't tell about that reasoning, but it might make sense in a way I don't\nunderstand yet ...\n\n> I think it would be better to either just reject relative paths entirely, or\n> accept any relative path as-is and display a warning that the submodule is\n> only valid on the local machine. (Perhaps one day receive-pack could even be\n> taught to reject any pushes with a .gitmodules file containing a relative URL.)\n\nBreaking backwards compatibility should not be considered easily. I tend to\nnot change such things until I understand the use cases for the solution,\nespecially as submodule use cases tend to be very different ...\n\n\n git-submodule.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex d189a24..587d74e 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -34,7 +34,7 @@ resolve_relative_url ()\n {\n \tremote=$(get_default_remote)\n \tremoteurl=$(git config \"remote.$remote.url\") ||\n-\t\tdie \"remote ($remote) does not have a url defined in .git/config\"\n+\t\tdie \"Cannot resolve \\\"$1\\\" relative to this repository's \\\"$remote\\\" remote: The remote's URL is not set in .git/config\"\n \turl=\"$1\"\n \tremoteurl=${remoteurl%/}\n \tsep=/\n-- \n1.7.5.3.445.g9c0c23\n"},{"id":"169080","messageId":"4DE565DF.7050207@cisco.com","threadId":"27505","inReplyTo":"4DE5561C.3010200@xiplink.com","subject":"Re: [PATCH] submodule add: improve message when resolving a relative url fails","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-05-31T22:04:15Z","receivedAt":"2011-05-31T22:04:15Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 05/31/2011 04:57 PM, Marc Branchaud wrote:\n> Thanks for the cogent explanation & patch. I think the message could be\n> improved a bit:\n>\n> \tCannot resolve \"../sub\" relative to this repository's \"origin\"\n> \tremote: The remote's URL is not set in .git/config\n>\n> However, overall I think this is a pretty fragile way to handle relative\n> paths. Consider:\n>\n> - The super-repo must be a clone in order for this to work at all.\n\nYes, but that constraint (mostly) makes sense to me. But if 'git\nsubmodule add' did not initialize .git/config, this constraint could be\ndropped.\n\n> - The super-repo cannot be checked out on a detached HEAD.\n\nWhy do you think that? I just tried this and it worked fine for me. I\ncan't think of a reason for it to fail.\n\n> - The current code rewrites the URL so that any relative path is either\n> rejected or munged into an absolute remote URL.\n\nI don't see the URL getting munged away from being relative. Can you\npoint to an example?\n\n> It seems to me that this feature will only work in a fairly narrow set of\n> circumstances, and even when it does work it's likely to do something\n> unexpected (think of a super-repo with several remotes).\n\nI use it this way with several remotes. \n\n> Back when Junio accepted the original patch, he said \"If you maintain and\n> serve a set related projects you need to give the users a single URL (per\n> where the user is and how to reach the server).\" I'm not sure I understand\n> that: Why would the users be adding their own submodules to the\n> superproject? Wouldn't the superproject define the submodules in for them?\nI am a user. I admin a super-project for other users. This project\nlives at three remotes, remotes/public, remotes/shared and remotes/build. \n\nI add a new submodule to the superproject like this:\n\n mkdir sub && cd sub && git init\n cd ..\n git submodule add ../sub sub\n\nThis results in the new submodule being inserted into my .gitmodules\nfile and my .git/config:\n\n tail -3 .gitmodules\n [submodule \"sub\"]\n path = sub\n url = ../sub\n\n tail -2 .git/config\n [submodule \"sub\"]\n url = public:git/sub\n\nI do have to make sure to push my submodule to the correct location on\neach remote before pushing my new .gitmodules.\n\nBut the exact same commands work for me if I do this first and then do\n'git submodule add ../sub' afterwards. \n\nSo, I don't understand your objections. Do you understand my use case\nany better?\n\nPhil\n"},{"id":"169085","messageId":"7vaae2ihe1.fsf@alter.siamese.dyndns.org","threadId":"27505","inReplyTo":"4DE5561C.3010200@xiplink.com","subject":"Re: [PATCH] submodule add: improve message when resolving a relative url fails","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-31T23:23:34Z","receivedAt":"2011-05-31T23:23:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> Back when Junio accepted the original patch, he said \"If you maintain and\n> serve a set related projects you need to give the users a single URL (per\n> where the user is and how to reach the server).\"\n\nI think it was phrased badly. At least it should have s/need/only need/;\n\nImagine ta project has many components, all of which are kept as\nsubmodules of a single top-level superproject. You wrote and manage\neverything; there is no borrowed code. In that context, imagine that I am\ntalking to the maintainer of that set of projects and calling the person\n\"you\".\n\nBy giving the URL for the top-level superproject, without having to give\nany other URL for the subprojects, you can let your users fetch from you,\nas everything underneath is relative. Another convenience this may give\nyou and your users is when the user needs to talk to you over different\ntransport. You may give \"git://your.site/project.git\" to the users, but\nthey may come to \"http://your.site/project.git\".\n\nBy recording submodule..url as relative to where your users happen\nto have fetched your project in the superproject's .gitmodules file, your\nusers do not have to run around fixing URLs for 47 different component\nsubmodules.\n\nAt least I think that is what I meant back then.\n"},{"id":"169117","messageId":"4DE660E2.9080500@xiplink.com","threadId":"27505","inReplyTo":"4DE565DF.7050207@cisco.com","subject":"Re: [PATCH] submodule add: improve message when resolving a relative url fails","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-06-01T15:55:14Z","receivedAt":"2011-06-01T15:55:14Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-05-31 06:04 PM, Phil Hord wrote:\n> On 05/31/2011 04:57 PM, Marc Branchaud wrote:\n>> Thanks for the cogent explanation & patch. I think the message could be\n>> improved a bit:\n>>\n>> \tCannot resolve \"../sub\" relative to this repository's \"origin\"\n>> \tremote: The remote's URL is not set in .git/config\n>>\n>> However, overall I think this is a pretty fragile way to handle relative\n>> paths. Consider:\n>>\n>> - The super-repo must be a clone in order for this to work at all.\n> \n> Yes, but that constraint (mostly) makes sense to me. But if 'git\n> submodule add' did not initialize .git/config, this constraint could be\n> dropped.\n> \n>> - The super-repo cannot be checked out on a detached HEAD.\n> \n> Why do you think that? I just tried this and it worked fine for me. I\n> can't think of a reason for it to fail.\n\nWhoops, right. I was confusing a different error with the fact that \"git\nsymbolic-ref HEAD\" fails on a detached HEAD. The code defaults to \"origin\"\nas the remote name in this case (perhaps that's not strictly the right thing\nto do, but I'm sure this isn't the only part of git that assumes there's a\nremote called \"origin\").\n\n>> - The current code rewrites the URL so that any relative path is either\n>> rejected or munged into an absolute remote URL.\n> \n> I don't see the URL getting munged away from being relative. Can you\n> point to an example?\n\nI reached this conclusion because if I go into my clone of git.git and do\n\n\tgit submodule add ../MyThing\n\nwhere ../MyThing is a regular git repo, I get\n\nCloning into MyThing...\nfatal: The remote end hung up unexpectedly\nClone of 'git://git.kernel.org/pub/scm/git/MyThing' into submodule path\n'MyThing' failed\n\nSo it seemed the relative URL became an absolute URL.\n\nLooking more closely at a working example, I can see that (as you show below)\nthe URL in the super-repo's .gitmodules file retains the relative path, but\nthe submodule's remote.origin.url is an absolute path.\n\nIn any case, \"submodule add\" isn't doing what I expected: make my local\nMyThing repo a submodule of my git.git clone.\n\n>> It seems to me that this feature will only work in a fairly narrow set of\n>> circumstances, and even when it does work it's likely to do something\n>> unexpected (think of a super-repo with several remotes).\n> \n> I use it this way with several remotes. \n> \n>> Back when Junio accepted the original patch, he said \"If you maintain and\n>> serve a set related projects you need to give the users a single URL (per\n>> where the user is and how to reach the server).\" I'm not sure I understand\n>> that: Why would the users be adding their own submodules to the\n>> superproject? Wouldn't the superproject define the submodules in for them?\n> I am a user. I admin a super-project for other users. This project\n> lives at three remotes, remotes/public, remotes/shared and remotes/build. \n> \n> I add a new submodule to the superproject like this:\n> \n> mkdir sub && cd sub && git init\n> cd ..\n> git submodule add ../sub sub\n> \n> This results in the new submodule being inserted into my .gitmodules\n> file and my .git/config:\n> \n> tail -3 .gitmodules\n> [submodule \"sub\"]\n> path = sub\n> url = ../sub\n> \n> tail -2 .git/config\n> [submodule \"sub\"]\n> url = public:git/sub\n> \n> I do have to make sure to push my submodule to the correct location on\n> each remote before pushing my new .gitmodules.\n> \n> But the exact same commands work for me if I do this first and then do\n> 'git submodule add ../sub' afterwards. \n> \n> So, I don't understand your objections. Do you understand my use case\n> any better?\n\nIt's not so much an objection as confusion over how \"submodule add\" works.\n\nI believe your case works smoothly only because in your super-project you're\ncareful to make sure you have checked out a branch that remotely tracks a\nsomething in remotes/public. If you checked out a branch that tracks a\ndifferent remote you'd get different results. This seems fragile to me.\n\nWhen you tried the detached-HEAD scenario, did you get URLs for\n\"public:git/sub\" or \"origin:git/sub\"? Does \"origin\" just happen to be the\nremote you want to use in any case?\n\nMy fundamental point is that \"git submodule add\" seems to do confusing things\nwith relative paths. Maybe all that's needed is to clarify the\ndocumentation. I'll post a patch.\n\n\t\tM.\n"},{"id":"169118","messageId":"1306943792-1825-1-git-send-email-marcnarc@xiplink.com","threadId":"27505","inReplyTo":"7vaae2ihe1.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-06-01T15:56:32Z","receivedAt":"2011-06-01T15:56:32Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Signed-off-by: Marc Branchaud \n---\n Documentation/git-submodule.txt | 13 +++++++++++--\n 1 files changed, 11 insertions(+), 2 deletions(-)\n\nOn 11-05-31 07:23 PM, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> Back when Junio accepted the original patch, he said \"If you maintain and\n>> serve a set related projects you need to give the users a single URL (per\n>> where the user is and how to reach the server).\"\n> \n> I think it was phrased badly. At least it should have s/need/only need/;\n> \n> Imagine ta project has many components, all of which are kept as\n> submodules of a single top-level superproject. You wrote and manage\n> everything; there is no borrowed code. In that context, imagine that I am\n> talking to the maintainer of that set of projects and calling the person\n> \"you\".\n> \n> By giving the URL for the top-level superproject, without having to give\n> any other URL for the subprojects, you can let your users fetch from you,\n> as everything underneath is relative. Another convenience this may give\n> you and your users is when the user needs to talk to you over different\n> transport. You may give \"git://your.site/project.git\" to the users, but\n> they may come to \"http://your.site/project.git\".\n> \n> By recording submodule..url as relative to where your users happen\n> to have fetched your project in the superproject's .gitmodules file, your\n> users do not have to run around fixing URLs for 47 different component\n> submodules.\n> \n> At least I think that is what I meant back then.\n\nI see -- I was confused by the phrase \"give ... a single URL\" (since the\nURLs are already in the .gitmodules file, how is there ever any need to\ngive more than one URL?).\n\nSo this is really about saving the users the hassle of modifying all the\nURLs in the .gitmodules file. Does this patch document what you mean?\n\n\t\tM.\n\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 1a16ff6..54dfebb 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -77,8 +77,17 @@ to exist in the superproject. If is not given, the\n +\n is the URL of the new submodule's origin repository.\n This may be either an absolute URL, or (if it begins with ./\n-or ../), the location relative to the superproject's origin\n-repository.\n+or ../) a URL relative to one of the superproject's remote\n+repostories: If the superprojet's currently checked-out branch tracks\n+a remote branch then that remote's URL is used, otherwise the \"origin\"\n+remote's URL is used. Relative URLs allow users to easily clone the\n+superproject and its submodules using a different URL than what the\n+superproject's maintainer might use (e.g. the maintainer can use ssh://\n+URLs while the users might use git:// URLs). With relative URLs in the\n+.gitmodules file, the users won't have to edit all the submodule URLs.\n++\n+*NOTE*: This means that you can *not* use a relative path to refer to a\n+repository in your local filesystem.\n +\n is the relative location for the cloned submodule to\n exist in the superproject. If does not exist, then the\n-- \n1.7.5.3.1.ge85f0\n"},{"id":"169122","messageId":"4DE664A1.5060206@xiplink.com","threadId":"27505","inReplyTo":"4DE55D0F.1020905@web.de","subject":"Re: [PATCH 0/2] Tests for some submodule corner cases.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-06-01T16:11:13Z","receivedAt":"2011-06-01T16:11:13Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-05-31 05:26 PM, Jens Lehmann wrote:\n> Am 31.05.2011 23:06, schrieb Marc Branchaud:\n>> On 11-05-31 03:30 PM, Jens Lehmann wrote:\n>>> Am 30.05.2011 23:51, schrieb Marc Branchaud:\n>>>> Patch 2 exposes an anomaly in \"submodule status\", which reports that a\n>>>> submodule is OK even though it has deleted files. \"git status\" inside\n>>>> the submodule (and in the super-repo) both identify any deleted files, but\n>>>> \"submodule status\" doesn't prefix the submodule's HEAD SHA-ID with a \"+\".\n>>>\n>>> That is documented behavior. \"git submodule status\" only cares about the\n>>> commit recorded in the superproject vs the HEAD in the submodule, work\n>>> tree modifications are never shown by it.\n>>>\n>>> But try a \"git status\" in the superproject, that will give you the following\n>>> output:\n>>> #\tmodified: init (modified content)\n>>\n>> I understand. My apologies for not reading the man page closely enough.\n> \n> No problem, maybe that's just an indication that a reference to \"git status\"\n> being more capable of telling what is going on inside a submodule is missing\n> to the man page for \"git submodule status\".\n\nYes, that'd possibly help.\n\n>> I know there's been a lot of recent work on making \"git status\"\n>> submodule-friendly, but would there be any interest in having another prefix\n>> for submodule status to cover this case? Maybe ! could indicate that the\n>> submodule's HEAD is correct, but the working directory doesn't match it exactly.\n> \n> I'd rather leave \"git submodule status\" as it is and incorporate this kind\n> of functionality into core git (for \"submodule status\" it already arrived there\n> in 1.7.0/1.7.1, so that part is finished ;-). I hope making the \"git submodule\"\n> script mostly obsolete in the long run and would want to avoid teaching it new\n> stuff already covered by core git.\n\nA noble goal, certainly.\n\nSo here's my basic question: How can my build system be sure that a submodule\ncontains the correct working directory? Do I need to do both \"git submodule\nstatus\" to check the submodule's HEAD, then also use \"git status\" to see if\nthat HEAD is correctly checked out?\n\nNote that my automated builds don't really care about possibly-modified files\nor anything like that. They just want the exact tree that corresponds to the\ncommit ID recorded in the superproject. (Previous builds might've left some\ncruft lying around, and the automated build wants to be sure that's eliminated.)\n\nMaybe I should just forego the status-checking altogether, and do \"git\nsubmodule update path/to/sub && (cd path/to/sub; git reset --hard HEAD; git\nclean -dx)\".\n\n\t\tM.\n"},{"id":"169129","messageId":"7vsjrth4iy.fsf@alter.siamese.dyndns.org","threadId":"27505","inReplyTo":"1306943792-1825-1-git-send-email-marcnarc@xiplink.com","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-01T16:59:01Z","receivedAt":"2011-06-01T16:59:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> So this is really about saving the users the hassle of modifying all the\n> URLs in the .gitmodules file. Does this patch document what you mean?\n\nI do not necessarily think it is _solely_ about users. Another obvious\nexample I left unsaid was what would happen when your project gets popular\nand gets mirrored to many places. Surely you need to advise people of\nalternate locations of the top-level, but what is recorded in .gitmodules\nwill be relative to that top-level, so they do not have to be changed.\nEven if you have only one public repository, I would imagine that the same\nconvenience would apply if you ever decide to switch the project hosting\nsite.\n\n\"Users can use a URL different from what was given by the maintainer\" is\nmerely an example; I doubt it deserves stressing that much.\n\n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index 1a16ff6..54dfebb 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -77,8 +77,17 @@ to exist in the superproject. If is not given, the\n> +\n> is the URL of the new submodule's origin repository.\n> This may be either an absolute URL, or (if it begins with ./\n> -or ../), the location relative to the superproject's origin\n> -repository.\n> +or ../) a URL relative to one of the superproject's remote\n> +repostories: If the superprojet's currently checked-out branch tracks\n> +a remote branch then that remote's URL is used, otherwise the \"origin\"\n> +remote's URL is used. Relative URLs allow users to easily clone the\n> +superproject and its submodules using a different URL than what the\n> +superproject's maintainer might use (e.g. the maintainer can use ssh://\n> +URLs while the users might use git:// URLs). With relative URLs in the\n> +.gitmodules file, the users won't have to edit all the submodule URLs.\n> ++\n> +*NOTE*: This means that you can *not* use a relative path to refer to a\n> +repository in your local filesystem.\n\nIt is not \"can not\" but \"do not\", is it? More importantly, I do not think\nit is limited to the case of relative path at all.\n\nI thought that in general \"submodule add\" takes a URL and never a _local_\nfilesystem location, as the whole point [*1*] of running \"submodule add\"\ncommand is to update the entry in the .gitmodules file for people who may\nnot have access to _your_ local filesystem in the first place?\n\nI am starting to suspect that the original confusion that started this\nthread is coming from misunderstanding in this area.\n\n[Footnote]\n\n*1* The command also adds a corresponding entry to your own .git/config\nfile so that you can work as if you are just one of your users and as if\nyou did \"submodule init\" based on what is in .gitmodules.\n"},{"id":"169134","messageId":"7vboyhh2eq.fsf@alter.siamese.dyndns.org","threadId":"27505","inReplyTo":"4DE664A1.5060206@xiplink.com","subject":"Re: [PATCH 0/2] Tests for some submodule corner cases.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-01T17:44:45Z","receivedAt":"2011-06-01T17:44:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> Note that my automated builds don't really care about possibly-modified files\n> or anything like that. They just want the exact tree that corresponds to the\n> commit ID recorded in the superproject. (Previous builds might've left some\n> cruft lying around, and the automated build wants to be sure that's eliminated.)\n>\n> Maybe I should just forego the status-checking altogether, and do \"git\n> submodule update path/to/sub && (cd path/to/sub; git reset --hard HEAD; git\n> clean -dx)\".\n\nIt really depends on what you really care about. If the working tree is\nshared between your build-bot and a human user, the build-bot may want to\nmake sure it does not overwrite and lose work by a human, but otherwise,\ninstead of checking if something is stale (and having to design what to do\nwhen it actually finds something is stale), actively causing the state it\nwants to see appear in the working tree sounds like a simpler, more robust\nand much saner thing to do.\n"},{"id":"169142","messageId":"4DE6927A.8010902@web.de","threadId":"27505","inReplyTo":"4DE664A1.5060206@xiplink.com","subject":"Re: [PATCH 0/2] Tests for some submodule corner cases.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-01T19:26:50Z","receivedAt":"2011-06-01T19:26:50Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 01.06.2011 18:11, schrieb Marc Branchaud:\n> On 11-05-31 05:26 PM, Jens Lehmann wrote:\n>> No problem, maybe that's just an indication that a reference to \"git status\"\n>> being more capable of telling what is going on inside a submodule is missing\n>> to the man page for \"git submodule status\".\n> \n> Yes, that'd possibly help.\n\nOk, I'll see if I can come up with something ...\n\n> So here's my basic question: How can my build system be sure that a submodule\n> contains the correct working directory? Do I need to do both \"git submodule\n> status\" to check the submodule's HEAD, then also use \"git status\" to see if\n> that HEAD is correctly checked out?\n\nNo, \"git status\" will do both. The only thing it will be silent about is when\na submodule isn't initialized at all (\"git submodule status\" shows this with\na '-').\n"},{"id":"169145","messageId":"4DE69945.1080601@web.de","threadId":"27505","inReplyTo":"7vsjrth4iy.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-01T19:55:49Z","receivedAt":"2011-06-01T19:55:49Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 01.06.2011 18:59, schrieb Junio C Hamano:\n> I thought that in general \"submodule add\" takes a URL and never a _local_\n> filesystem location, as the whole point [*1*] of running \"submodule add\"\n> command is to update the entry in the .gitmodules file for people who may\n> not have access to _your_ local filesystem in the first place?\n\nI often use a local filesystem location for shared code I'm using in some\npersonal projects, mainly because I want to avoid the hassle of setting\nup a server location for it (and the git test suite uses that feature too\nfor similar reasons). That doesn't make much sense when working together\nwith others, but that is not an issue in these use cases.\n\nSo I see three different location types supported by current submodule\nadd:\n 1) a URL reachable by you and your coworkers\n 2) a path relative to the URL of the superproject's default remote\n 3) A local filesystem location which can only be shared locally\nAnd each of them has its merits and uses (and using two of them everyday\nmight make it easy to overlook the third ;-)\n"},{"id":"169195","messageId":"1307024488-10130-1-git-send-email-marcnarc@xiplink.com","threadId":"27505","inReplyTo":"7vsjrth4iy.fsf@alter.siamese.dyndns.org","subject":"[PATCHv2] Clarified how \"git submodule add\" handles relative paths.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-06-02T14:21:28Z","receivedAt":"2011-06-02T14:21:28Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Signed-off-by: Marc Branchaud \n---\n Documentation/git-submodule.txt | 17 +++++++++++++++--\n 1 files changed, 15 insertions(+), 2 deletions(-)\n\nOn 11-06-01 12:59 PM, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> So this is really about saving the users the hassle of modifying all the\n>> URLs in the .gitmodules file. Does this patch document what you mean?\n> \n> I do not necessarily think it is _solely_ about users. Another obvious\n> example I left unsaid was what would happen when your project gets popular\n> and gets mirrored to many places. Surely you need to advise people of\n> alternate locations of the top-level, but what is recorded in .gitmodules\n> will be relative to that top-level, so they do not have to be changed.\n> Even if you have only one public repository, I would imagine that the same\n> convenience would apply if you ever decide to switch the project hosting\n> site.\n\nI think I understand. How does this version grab ya?\n\n> \"Users can use a URL different from what was given by the maintainer\" is\n> merely an example; I doubt it deserves stressing that much.\n> \n>> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n>> index 1a16ff6..54dfebb 100644\n>> --- a/Documentation/git-submodule.txt\n>> +++ b/Documentation/git-submodule.txt\n>> @@ -77,8 +77,17 @@ to exist in the superproject. If is not given, the\n>> +\n>> is the URL of the new submodule's origin repository.\n>> This may be either an absolute URL, or (if it begins with ./\n>> -or ../), the location relative to the superproject's origin\n>> -repository.\n>> +or ../) a URL relative to one of the superproject's remote\n>> +repostories: If the superprojet's currently checked-out branch tracks\n>> +a remote branch then that remote's URL is used, otherwise the \"origin\"\n>> +remote's URL is used. Relative URLs allow users to easily clone the\n>> +superproject and its submodules using a different URL than what the\n>> +superproject's maintainer might use (e.g. the maintainer can use ssh://\n>> +URLs while the users might use git:// URLs). With relative URLs in the\n>> +.gitmodules file, the users won't have to edit all the submodule URLs.\n>> ++\n>> +*NOTE*: This means that you can *not* use a relative path to refer to a\n>> +repository in your local filesystem.\n> \n> It is not \"can not\" but \"do not\", is it? More importantly, I do not think\n> it is limited to the case of relative path at all.\n\nWell, the way the code currently works I think it's \"can not\". It'll\nhappily accept an absolute file path but any relative path is either\nsuccessfully \"remotified\" or the command fails.\n\n(I also agree with Jens that there's utility in allowing local-filesystem\nsubmodules.)\n\n\t\tM.\n\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 1a16ff6..8daa33c 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -77,8 +77,21 @@ to exist in the superproject. If is not given, the\n +\n is the URL of the new submodule's origin repository.\n This may be either an absolute URL, or (if it begins with ./\n-or ../), the location relative to the superproject's origin\n-repository.\n+or ../) a URL relative to one of the superproject's remote\n+repostories: If the superprojet's currently checked-out branch tracks\n+a remote branch then that remote's URL is used, otherwise the \"origin\"\n+remote's URL is used.\n++\n+Relative submodule URLs provide flexibility in cases where the\n+super-project and its submodules are hosted together. For example,\n+the relative submodule URLs remain valid if the repository collection\n+moves to a different hosting site, or if the collection is mirrored at\n+different sites. Similarly, maintainers can conveniently make clones\n+with a different URL (say an ssh:// URL) than users (who might use\n+git:// URLs).\n++\n+*NOTE*: This means that you can *not* use a relative path to refer to a\n+repository in your local filesystem.\n +\n is the relative location for the cloned submodule to\n exist in the superproject. If does not exist, then the\n-- \n1.7.5.3.1.ge85f0.dirty\n"},{"id":"169207","messageId":"7v39jsdulf.fsf@alter.siamese.dyndns.org","threadId":"27505","inReplyTo":"4DE69945.1080601@web.de","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-02T17:14:04Z","receivedAt":"2011-06-02T17:14:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> I often use a local filesystem location for shared code I'm using in some\n> personal projects, mainly because I want to avoid the hassle of setting\n> up a server location for it (and the git test suite uses that feature too\n> for similar reasons). That doesn't make much sense when working together\n> with others, but that is not an issue in these use cases.\n>\n> So I see three different location types supported by current submodule\n> add:\n> 1) a URL reachable by you and your coworkers\n> 2) a path relative to the URL of the superproject's default remote\n> 3) A local filesystem location which can only be shared locally\n> And each of them has its merits and uses (and using two of them everyday\n> might make it easy to overlook the third ;-)\n\nI suspect that it would be a relatively easy fix if your toplevel\nsuperproject is its own authoritative upstream. Something along the line\nof this patch, perhaps? It is obviously untested, and we may want to\nissue an \"echo >&2 'info:...'\" to tell the user what we are assuming in\nthis codepath.\n\n git-submodule.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex b010a67..6d27729 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -34,7 +34,7 @@ resolve_relative_url ()\n {\n \tremote=$(get_default_remote)\n \tremoteurl=$(git config \"remote.$remote.url\") ||\n-\t\tdie \"remote ($remote) does not have a url defined in .git/config\"\n+\tremoteurl=$(pwd) # the repository is its own authoritative upstream\n \turl=\"$1\"\n \tremoteurl=${remoteurl%/}\n \tsep=/\n"},{"id":"169267","messageId":"4DE93B29.4030401@web.de","threadId":"27505","inReplyTo":"7v39jsdulf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-03T19:51:05Z","receivedAt":"2011-06-03T19:51:05Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 02.06.2011 19:14, schrieb Junio C Hamano:\n> I suspect that it would be a relatively easy fix if your toplevel\n> superproject is its own authoritative upstream. Something along the line\n> of this patch, perhaps? It is obviously untested, and we may want to\n> issue an \"echo >&2 'info:...'\" to tell the user what we are assuming in\n> this codepath.\n\nMaybe it is better to not automagically switch from \"path is relative to\nurl configured in superproject\" to \"path is relative to $(pwd)\" depending\non the presence or absence of a default remote in the superproject. When\na user wants to set up his submodules relative to the superproject and\nsimply did forget to configure the url of the superproject first he won't\nnotice that anymore after this patch. But instead he will get a local\nsubmodule url only to find out later that this was not what I wanted (and\nan 'info' can easily be missed).\n\nNow I understand this issue better I'd vote for leaving the relative url\nlike it is, comment it better in the man page and give a better error\nmessage when that happens. After all this issue only surprised a few\npeople, mostly due to the lack of information in the error message and\nman page, so I'd rather prefer to not change the behavior but the wording.\n"},{"id":"169281","messageId":"7vhb86a4kt.fsf@alter.siamese.dyndns.org","threadId":"27505","inReplyTo":"4DE93B29.4030401@web.de","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-03T23:16:34Z","receivedAt":"2011-06-03T23:16:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Now I understand this issue better I'd vote for leaving the relative url\n> like it is, comment it better in the man page and give a better error\n> message when that happens. After all this issue only surprised a few\n> people, mostly due to the lack of information in the error message and\n> man page, so I'd rather prefer to not change the behavior but the wording.\n\nThe \"how about this\" patch you are voting against (I am neutral by the\nway) is a response to your earlier \"I have three use cases and the current\nimplementation is forgetting the third\", which in turn was a response to\nmy \"your third use case does not count, so the updated wording of the\ndocumentation is wrong---it should say 'do not', not 'cannot'\".\n\nSo what should the updated document say?\n"},{"id":"169298","messageId":"4DE99724.9090607@gmail.com","threadId":"27505","inReplyTo":"7vhb86a4kt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2011-06-04T02:23:32Z","receivedAt":"2011-06-04T02:23:32Z","isPatch":true,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 06/03/2011 07:16 PM, Junio C Hamano wrote:\n> Jens Lehmann writes:\n> The \"how about this\" patch you are voting against (I am neutral by the\n> way) is a response to your earlier \"I have three use cases and the current\n> implementation is forgetting the third\", which in turn was a response to\n> my \"your third use case does not count, so the updated wording of the\n> documentation is wrong---it should say 'do not', not 'cannot'\".\n>\n> So what should the updated document say?\n>\nIf I understand this correctly, the third use case isn't actually \nunique: if the upstream repo is on a local file system, why not just use \na file://... url for the super project's origin?\n\nMark\n"},{"id":"169303","messageId":"4DEA51A3.3000603@web.de","threadId":"27505","inReplyTo":"4DE99724.9090607@gmail.com","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-04T15:39:15Z","receivedAt":"2011-06-04T15:39:15Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 04.06.2011 04:23, schrieb Mark Levedahl:\n> On 06/03/2011 07:16 PM, Junio C Hamano wrote:\n>> Jens Lehmann writes:\n>> The \"how about this\" patch you are voting against (I am neutral by the\n>> way) is a response to your earlier \"I have three use cases and the current\n>> implementation is forgetting the third\", which in turn was a response to\n>> my \"your third use case does not count, so the updated wording of the\n>> documentation is wrong---it should say 'do not', not 'cannot'\".\n>>\n>> So what should the updated document say?\n>>\n> If I understand this correctly, the third use case isn't actually unique: if the upstream repo is on a local file system, why not just use a file://... url for the super project's origin?\n\nRight, if you use a \"file:/\" scheme these two cases become one. But you\ncan omit the \"file:/\" scheme part and it will still give the same result.\n(So if the file scheme would be regarded as default the third case would\nalready be covered by the url case)\n"},{"id":"169305","messageId":"4DEA5B03.7020704@web.de","threadId":"27505","inReplyTo":"7vhb86a4kt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-04T16:19:15Z","receivedAt":"2011-06-04T16:19:15Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 04.06.2011 01:16, schrieb Junio C Hamano:\n> Jens Lehmann writes:\n> \n>> Now I understand this issue better I'd vote for leaving the relative url\n>> like it is, comment it better in the man page and give a better error\n>> message when that happens. After all this issue only surprised a few\n>> people, mostly due to the lack of information in the error message and\n>> man page, so I'd rather prefer to not change the behavior but the wording.\n> \n> The \"how about this\" patch you are voting against (I am neutral by the\n> way) is a response to your earlier \"I have three use cases and the current\n> implementation is forgetting the third\", which in turn was a response to\n> my \"your third use case does not count, so the updated wording of the\n> documentation is wrong---it should say 'do not', not 'cannot'\".\n> \n> So what should the updated document say?\n\nI think that for the improved error message the v2 of my 'submodule add:\nimprove message when resolving a relative url fails' should be sufficient.\n\nFor the documentation I'd propose to apply Marc's 'Clarified how \"git\nsubmodule add\" handles relative paths.' patch with the interdiff below\nsquashed in. It fixes a typo and explains that absolute paths are allowed\ntoo (and join case three with the absolute url one by using a \"file://\"\nscheme as default, which is what Mark hinted in his email).\n\nIf you want me to resend these two as an updated series just let me know.\n---------- 8< ----------\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 2294fa6..99d0a83 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -76,9 +76,10 @@ to exist in the superproject. If is not given, the\n \"/path/to/repo.git\" and \"foo\" for \"host.xz:foo/.git\").\n +\n is the URL of the new submodule's origin repository.\n-This may be either an absolute URL, or (if it begins with ./\n+This may be either an absolute URL (when the scheme part is not\n+specified \"file://\" is assumed) or (if it begins with ./\n or ../) a URL relative to one of the superproject's remote\n-repostories: If the superprojet's currently checked-out branch tracks\n+repostories: If the superproject's currently checked-out branch tracks\n a remote branch then that remote's URL is used, otherwise the \"origin\"\n remote's URL is used. Relative URLs allow users to easily clone the\n superproject and its submodules using a different URL than what the\n"},{"id":"169324","messageId":"7vipskb0br.fsf@alter.siamese.dyndns.org","threadId":"27505","inReplyTo":"4DE93B29.4030401@web.de","subject":"Re: [PATCH] Clarified how \"git submodule add\" handles relative paths.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-05T18:27:36Z","receivedAt":"2011-06-05T18:27:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Am 02.06.2011 19:14, schrieb Junio C Hamano:\n>> I suspect that it would be a relatively easy fix if your toplevel\n>> superproject is its own authoritative upstream. Something along the line\n>> of this patch, perhaps? It is obviously untested, and we may want to\n>> issue an \"echo >&2 'info:...'\" to tell the user what we are assuming in\n>> this codepath.\n>\n> Maybe it is better to not automagically switch from \"path is relative to\n> url configured in superproject\" to \"path is relative to $(pwd)\" depending\n> on the presence or absence of a default remote in the superproject. When\n> a user wants to set up his submodules relative to the superproject and\n> simply did forget to configure the url of the superproject first he won't\n> notice that anymore after this patch. But instead he will get a local\n> submodule url only to find out later that this was not what I wanted (and\n> an 'info' can easily be missed).\n\nSorry, I don't get this. The \"how-about-this\" patch was not about\n\"automagically switch depending on ...\". Absense of the remote in the\nsuperproject means that the project originates from here, iow, it is its\nown \"origin\" (that is your third use case).\n\nI think I understand the scenario you are worried about; let me illustrate\nto make sure I got it right:\n\n 1. You are starting your project that will have subproject locally. You do\n not have \"origin\" yet.\n\n 2. You create a subproject \"xyzzy\", still locally, and add it with\n \"submodule add ./xyzzy\" with a relative URL.\n\n 3. You will deploy your superproject and subproject at \"git://host.xz/mine/\"\n and \"git://host.xz/mine/xyzzy\", respectively.\n\n 4. But because in step 2. your .git/config is already set up to point\n your local $(pwd)/xyzzy as the submodule location. This is not what\n you want and you may not notice it.\n\nIs that the problem you are worried about? If so, I think you are solving\nit in a wrong way.\n\nBy not allowing a relative path, in step 2. you would entice the user to\nsay \"submodule add $(pwd)/xyzzy\" (as there is no final upstream location\nyet), no? If the project is going to be eventually published at a\ndifferent location, not just .git/config but .gitmodules also needs to be\nupdated as part of step 3. Isn't that going backwards? If you allow the\nuser to say \"./xyzzy\" in step 2., the .gitmodules entry can stay the same\nfrom the get-go.\n\nIf you think about \"absense of the remote in the superproject means the\nproject originates from here\", what you are doing in step 3. is to\nchanging the origin of these set of projects. After changing the origin of\nthese set of projects, isn't \"git submodule sync\" an established way to\nadjust to the change? I was hoping that that would update .git/config in\nstep 3. so you wouldn't have the problem in step 4. at all.\n\nIt is likely I am missing something in the above analysis. Please correct\nme.\n\nThanks.\n"},{"id":"169395","messageId":"4DED30E0.6090608@web.de","threadId":"27505","inReplyTo":"7vipskb0br.fsf@alter.siamese.dyndns.org","subject":"[PATCH 0/3] submodule add: allow relative repository path even when no url is set","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-06T19:56:16Z","receivedAt":"2011-06-06T19:56:16Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 05.06.2011 20:27, schrieb Junio C Hamano:\n> If you think about \"absense of the remote in the superproject means the\n> project originates from here\", what you are doing in step 3. is to\n> changing the origin of these set of projects. After changing the origin of\n> these set of projects, isn't \"git submodule sync\" an established way to\n> adjust to the change? I was hoping that that would update .git/config in\n> step 3. so you wouldn't have the problem in step 4. at all.\n\nThanks for explaining that in detail, I think I do get it now.\n\nSo what about this series: The first commit adds a test for the error we\nare talking about, the second one implements the logic you proposed and\nthe last one removes some duplicated code I stumbled across while staring\nat the code.\n\n\nJens Lehmann (3):\n submodule add: test failure when url is not configured in\n superproject\n submodule add: allow relative repository path even when no url is set\n submodule add: clean up duplicated code\n\n Documentation/git-submodule.txt | 4 +++-\n git-submodule.sh | 12 ++----------\n t/t7400-submodule-basic.sh | 10 ++++++++++\n 3 files changed, 15 insertions(+), 11 deletions(-)\n\n-- \n1.7.6.rc0.3.g28a66\n"},{"id":"169396","messageId":"4DED310D.9040300@web.de","threadId":"27505","inReplyTo":"4DED30E0.6090608@web.de","subject":"[PATCH 1/3] submodule add: test failure when url is not configured in superproject","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-06T19:57:01Z","receivedAt":"2011-06-06T19:57:01Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"This documents the current behavior (submodule add with the url set in the\nsuperproject is already tested in t7403, t7406, t7407 and t7506).\n\nSigned-off-by: Jens Lehmann \n---\n t/t7400-submodule-basic.sh | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex 874279e..cae5fd0 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -446,6 +446,13 @@ test_expect_success 'add should fail when path is used by an existing directory'\n \t)\n '\n\n+test_expect_success 'add should fail when path is relative but no url is set in the superproject' '\n+\t(\n+\t\tcd addtest &&\n+\t\ttest_must_fail git submodule add ../repo relative\n+\t)\n+'\n+\n test_expect_success 'set up for relative path tests' '\n \tmkdir reltest &&\n \t(\n-- \n1.7.6.rc0.3.g28a66\n"},{"id":"169397","messageId":"4DED314C.3000203@web.de","threadId":"27505","inReplyTo":"4DED30E0.6090608@web.de","subject":"[PATCH 2/3] submodule add: allow relative repository path even when no url is set","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-06T19:58:04Z","receivedAt":"2011-06-06T19:58:04Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Adding a submodule with a relative repository path did only succeed when\nthe superproject's default remote was set. But when that is unset, the\nsuperproject is its own authoritative upstream, so lets use its working\ndirectory as upstream instead.\n\nThis allows users to set up a new superpoject where the submodules urls\nare configured relative to the superproject's upstream while its default\nremote can be configured later.\n\nSigned-off-by: Jens Lehmann \n---\n Documentation/git-submodule.txt | 4 +++-\n git-submodule.sh | 2 +-\n t/t7400-submodule-basic.sh | 7 +++++--\n 3 files changed, 9 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 5e7a413..408998e 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -78,7 +78,9 @@ to exist in the superproject. If is not given, the\n is the URL of the new submodule's origin repository.\n This may be either an absolute URL, or (if it begins with ./\n or ../), the location relative to the superproject's origin\n-repository.\n+repository. If the superproject doesn't have an origin configured\n+the superproject is its own authoritative upstream and the current\n+working directory is used instead.\n +\n is the relative location for the cloned submodule to\n exist in the superproject. If does not exist, then the\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex d189a24..3fbc21e 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -34,7 +34,7 @@ resolve_relative_url ()\n {\n \tremote=$(get_default_remote)\n \tremoteurl=$(git config \"remote.$remote.url\") ||\n-\t\tdie \"remote ($remote) does not have a url defined in .git/config\"\n+\t\tremoteurl=$(pwd) # the repository is its own authoritative upstream\n \turl=\"$1\"\n \tremoteurl=${remoteurl%/}\n \tsep=/\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex cae5fd0..9099e80 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -446,10 +446,13 @@ test_expect_success 'add should fail when path is used by an existing directory'\n \t)\n '\n\n-test_expect_success 'add should fail when path is relative but no url is set in the superproject' '\n+test_expect_success 'use superproject as upstream when path is relative and no url is set there' '\n \t(\n \t\tcd addtest &&\n-\t\ttest_must_fail git submodule add ../repo relative\n+\t\tgit submodule add ../repo relative &&\n+\t\ttest \"$(git config -f .gitmodules submodule.relative.url)\" = ../repo &&\n+\t\tgit submodule sync relative &&\n+\t\ttest \"$(git config submodule.relative.url)\" = \"$submodurl/repo\"\n \t)\n '\n\n-- \n1.7.6.rc0.3.g28a66\n"},{"id":"169398","messageId":"4DED3173.20804@web.de","threadId":"27505","inReplyTo":"4DED30E0.6090608@web.de","subject":"[PATCH 3/3] submodule add: clean up duplicated code","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-06T19:58:43Z","receivedAt":"2011-06-06T19:58:43Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"In cmd_add() the switch statement used to resolve a relative url was\npresent twice. Remove the second one and use the realrepo variable set\nby the first one (lines 194 ff.) instead.\n\nSigned-off-by: Jens Lehmann \n---\n git-submodule.sh | 10 +---------\n 1 files changed, 1 insertions(+), 9 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 3fbc21e..2a727e1 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -238,15 +238,7 @@ cmd_add()\n \t\t\tdie \"'$path' already exists and is not a valid git repo\"\n \t\tfi\n\n-\t\tcase \"$repo\" in\n-\t\t./*|../*)\n-\t\t\turl=$(resolve_relative_url \"$repo\") || exit\n-\t\t ;;\n-\t\t*)\n-\t\t\turl=\"$repo\"\n-\t\t\t;;\n-\t\tesac\n-\t\tgit config submodule.\"$path\".url \"$url\"\n+\t\tgit config submodule.\"$path\".url \"$realrepo\"\n \telse\n\n \t\tmodule_clone \"$path\" \"$realrepo\" \"$reference\" || exit\n-- \n1.7.6.rc0.3.g28a66\n"},{"id":"169405","messageId":"1307393353-32389-1-git-send-email-marcnarc@xiplink.com","threadId":"27505","inReplyTo":"4DED314C.3000203@web.de","subject":"[PATCH 0/2] Improve \"git submodule add\" documentation.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-06-06T20:49:11Z","receivedAt":"2011-06-06T20:49:11Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"This series applies atop Jens's 2/3 patch. Jens, please feel free to\nsquash these into your commit if you like.\n\nThe first commit makes the documentation (hopefully) more accurately\ndescribe how git chooses which superproject remote to use.\n\nThe second commit moves the paragraph describing the utility of relative\nsubmodule URLs right after their description, making it more likely for\nreaders to see it (instead of assuming it's part of the parameter's\ndocumentation -- as I did on previous occasions).\n\n\t\tM.\n"},{"id":"169404","messageId":"1307393353-32389-2-git-send-email-marcnarc@xiplink.com","threadId":"27505","inReplyTo":"1307393353-32389-1-git-send-email-marcnarc@xiplink.com","subject":"[PATCH 1/2] More precisely described how \"git submodule add\" handles relative submodule URLs.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-06-06T20:49:12Z","receivedAt":"2011-06-06T20:49:12Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Signed-off-by: Marc Branchaud \n---\n Documentation/git-submodule.txt | 7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 408998e..83c59cc 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -77,8 +77,11 @@ to exist in the superproject. If is not given, the\n +\n is the URL of the new submodule's origin repository.\n This may be either an absolute URL, or (if it begins with ./\n-or ../), the location relative to the superproject's origin\n-repository. If the superproject doesn't have an origin configured\n+or ../) a location relative to one of the superproject's remote\n+repositories: If the superproject's currently checked-out branch tracks\n+a remote branch then that remote's URL is used, otherwise the \"origin\"\n+remote's URL is used.\n+If the superproject doesn't have an \"origin\" remote configured\n the superproject is its own authoritative upstream and the current\n working directory is used instead.\n +\n-- \n1.7.6.rc0.17.g3eac3\n"},{"id":"169403","messageId":"1307393353-32389-3-git-send-email-marcnarc@xiplink.com","threadId":"27505","inReplyTo":"1307393353-32389-1-git-send-email-marcnarc@xiplink.com","subject":"[PATCH 2/2] Moved paragraph describing the utility of relative submodule URLs.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-06-06T20:49:13Z","receivedAt":"2011-06-06T20:49:13Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Signed-off-by: Marc Branchaud \n---\n Documentation/git-submodule.txt | 16 ++++++++--------\n 1 files changed, 8 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 83c59cc..ad67541 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -85,6 +85,14 @@ If the superproject doesn't have an \"origin\" remote configured\n the superproject is its own authoritative upstream and the current\n working directory is used instead.\n +\n+In any case, the given URL is recorded into .gitmodules for\n+use by subsequent users cloning the superproject. If the URL is\n+given relative to the superproject's repository, the presumption\n+is the superproject and submodule repositories will be kept\n+together in the same relative location, and only the\n+superproject's URL needs to be provided: git-submodule will correctly\n+locate the submodule using the relative URL in .gitmodules.\n++\n is the relative location for the cloned submodule to\n exist in the superproject. If does not exist, then the\n submodule is created by cloning from the named URL. If does\n@@ -92,14 +100,6 @@ exist and is already a valid git repository, then this is added\n to the changeset without cloning. This second form is provided\n to ease creating a new submodule from scratch, and presumes\n the user will later push the submodule to the given URL.\n-+\n-In either case, the given URL is recorded into .gitmodules for\n-use by subsequent users cloning the superproject. If the URL is\n-given relative to the superproject's repository, the presumption\n-is the superproject and submodule repositories will be kept\n-together in the same relative location, and only the\n-superproject's URL needs to be provided: git-submodule will correctly\n-locate the submodule using the relative URL in .gitmodules.\n \n status::\n \tShow the status of the submodules. This will print the SHA-1 of the\n-- \n1.7.6.rc0.17.g3eac3\n"},{"id":"169409","messageId":"7vei368ylj.fsf@alter.siamese.dyndns.org","threadId":"27505","inReplyTo":"4DED30E0.6090608@web.de","subject":"Re: [PATCH 0/3] submodule add: allow relative repository path even when no url is set","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-06T21:00:08Z","receivedAt":"2011-06-06T21:00:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Am 05.06.2011 20:27, schrieb Junio C Hamano:\n>> If you think about \"absense of the remote in the superproject means the\n>> project originates from here\", what you are doing in step 3. is to\n>> changing the origin of these set of projects. After changing the origin of\n>> these set of projects, isn't \"git submodule sync\" an established way to\n>> adjust to the change? I was hoping that that would update .git/config in\n>> step 3. so you wouldn't have the problem in step 4. at all.\n>\n> Thanks for explaining that in detail, I think I do get it now.\n\nI actually still have a feeling that I may be missing something from the\ndiscussion. While I do like a solution that lifts existing limitation to\nallow workflows that were hitherto impossible, that only makes sense when\nthe newly allowed workflow makes sense and useful, and when the lifted\nlimitation was not protecting some silly mistakes from getting made.\n\nI _think_ our last exchange gave me a fuzzy confirmation that we are not\nlifting a useful limitation, but I still do not know if the new workflow\nmatches the workflow Marc (who kicked off this thread) wanted to use. I\nthink it does match the set-up Phil Hord mentioned in an earlier message,\nthough.\n"},{"id":"169411","messageId":"4DED454B.1050105@xiplink.com","threadId":"27505","inReplyTo":"7vei368ylj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/3] submodule add: allow relative repository path even when no url is set","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-06-06T21:23:23Z","receivedAt":"2011-06-06T21:23:23Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-06-06 05:00 PM, Junio C Hamano wrote:\n> Jens Lehmann writes:\n> \n>> Am 05.06.2011 20:27, schrieb Junio C Hamano:\n>>> If you think about \"absense of the remote in the superproject means the\n>>> project originates from here\", what you are doing in step 3. is to\n>>> changing the origin of these set of projects. After changing the origin of\n>>> these set of projects, isn't \"git submodule sync\" an established way to\n>>> adjust to the change? I was hoping that that would update .git/config in\n>>> step 3. so you wouldn't have the problem in step 4. at all.\n>>\n>> Thanks for explaining that in detail, I think I do get it now.\n> \n> I actually still have a feeling that I may be missing something from the\n> discussion. While I do like a solution that lifts existing limitation to\n> allow workflows that were hitherto impossible, that only makes sense when\n> the newly allowed workflow makes sense and useful, and when the lifted\n> limitation was not protecting some silly mistakes from getting made.\n> \n> I _think_ our last exchange gave me a fuzzy confirmation that we are not\n> lifting a useful limitation, but I still do not know if the new workflow\n> matches the workflow Marc (who kicked off this thread) wanted to use. I\n> think it does match the set-up Phil Hord mentioned in an earlier message,\n> though.\n\nWell, Jens's changes do remove the error I encountered, and they also do what\nI was expecting in the original context I was in when I started this thread.\n So I think this is a definite improvement.\n\nThere may still be a lingering niggle where git might do something the user\ndoesn't expect. For example, git might create a submodule out of\ngit://origin/foo.git instead of the local ../foo.git. You have to be paying\nattention to git's output to notice that difference, and I could see where a\nuser might get tripped up. But IMO improving this can be done independently\nof Jens's patches.\n\n\t\tM.\n"},{"id":"169412","messageId":"4DED4917.7020408@web.de","threadId":"27505","inReplyTo":"4DED454B.1050105@xiplink.com","subject":"Re: [PATCH 0/3] submodule add: allow relative repository path even when no url is set","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-06T21:39:35Z","receivedAt":"2011-06-06T21:39:35Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 06.06.2011 23:23, schrieb Marc Branchaud:\n> On 11-06-06 05:00 PM, Junio C Hamano wrote:\n>> Jens Lehmann writes:\n>>\n>>> Am 05.06.2011 20:27, schrieb Junio C Hamano:\n>>>> If you think about \"absense of the remote in the superproject means the\n>>>> project originates from here\", what you are doing in step 3. is to\n>>>> changing the origin of these set of projects. After changing the origin of\n>>>> these set of projects, isn't \"git submodule sync\" an established way to\n>>>> adjust to the change? I was hoping that that would update .git/config in\n>>>> step 3. so you wouldn't have the problem in step 4. at all.\n>>>\n>>> Thanks for explaining that in detail, I think I do get it now.\n>>\n>> I actually still have a feeling that I may be missing something from the\n>> discussion. While I do like a solution that lifts existing limitation to\n>> allow workflows that were hitherto impossible, that only makes sense when\n>> the newly allowed workflow makes sense and useful, and when the lifted\n>> limitation was not protecting some silly mistakes from getting made.\n\nThat's why I started with an improved error message and documentation ;-)\n\n>> I _think_ our last exchange gave me a fuzzy confirmation that we are not\n>> lifting a useful limitation, but I still do not know if the new workflow\n>> matches the workflow Marc (who kicked off this thread) wanted to use. I\n>> think it does match the set-up Phil Hord mentioned in an earlier message,\n>> though.\n> \n> Well, Jens's changes do remove the error I encountered, and they also do what\n> I was expecting in the original context I was in when I started this thread.\n> So I think this is a definite improvement.\n\nThanks.\n\n> There may still be a lingering niggle where git might do something the user\n> doesn't expect. For example, git might create a submodule out of\n> git://origin/foo.git instead of the local ../foo.git. You have to be paying\n> attention to git's output to notice that difference, and I could see where a\n> user might get tripped up. But IMO improving this can be done independently\n> of Jens's patches.\n\nMaybe Phil's opinion could be helpful here as he seems to be a heavy user of\nrelative submodule urls.\n"},{"id":"169507","messageId":"4DEE923E.9030208@web.de","threadId":"27505","inReplyTo":"4DED454B.1050105@xiplink.com","subject":"Re: [PATCH 0/3] submodule add: allow relative repository path even when no url is set","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-07T21:03:58Z","receivedAt":"2011-06-07T21:03:58Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 06.06.2011 23:23, schrieb Marc Branchaud:\n> On 11-06-06 05:00 PM, Junio C Hamano wrote:\n>> I actually still have a feeling that I may be missing something from the\n>> discussion. While I do like a solution that lifts existing limitation to\n>> allow workflows that were hitherto impossible, that only makes sense when\n>> the newly allowed workflow makes sense and useful, and when the lifted\n>> limitation was not protecting some silly mistakes from getting made.\n>>\n>> I _think_ our last exchange gave me a fuzzy confirmation that we are not\n>> lifting a useful limitation, but I still do not know if the new workflow\n>> matches the workflow Marc (who kicked off this thread) wanted to use. I\n>> think it does match the set-up Phil Hord mentioned in an earlier message,\n>> though.\n\nAfter thinking about this issue some more I think the change is good. We\nonly affect relative urls and obviously don't change the case where the\nurl is already set in the superproject (that case stays like it is and\nusers like Phil seem to like it that way).\n\nFor the case where the url is not set I see two use cases: The first for\npeople who would like to keep their submodules local (like me and Marc):\nthe new behavior enables us to use a relative path too, so we are happy.\nThen there are those who want to have a submodule relative to the super-\nprojects url: they won't get an error anymore when using a relative url\nwithout having a default remote in the superproject. But that is easily\nfixed later by doing a \"submodule sync\" when they recognize that fact,\njust like Junio explained.\n\n> There may still be a lingering niggle where git might do something the user\n> doesn't expect. For example, git might create a submodule out of\n> git://origin/foo.git instead of the local ../foo.git. You have to be paying\n> attention to git's output to notice that difference, and I could see where a\n> user might get tripped up. But IMO improving this can be done independently\n> of Jens's patches.\n\nThis behavior exists for some time and is not changed by the patches in\nquestion. But maybe when this patch is applied and people get used to\nrelative paths for local submodules that might become an issue when they\nrun into it. But I surely won't have an upstream defined for a superproject\nI want to add a local submodule too, so I doubt that.\n\nOr am I still missing something?\n"},{"id":"169607","messageId":"4DEF7644.1040204@cisco.com","threadId":"27505","inReplyTo":"4DEE923E.9030208@web.de","subject":"Re: [PATCH 0/3] submodule add: allow relative repository path even when no url is set","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-06-08T13:16:52Z","receivedAt":"2011-06-08T13:16:52Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"/(Pardon the duplicate; sending this again from my clean MUA.)\n/\nSometime last week, Marc Branchaud wrote:\n> I believe your case works smoothly only because in your super-project\n> you're careful to make sure you have checked out a branch that\n> remotely tracks a something in remotes/public. If you checked out a\n> branch that tracks a different remote you'd get different results.\n> This seems fragile to me.\n\nWell, I definitely wasn't careful, but in fact I _was_ on a\nremote-tracking branch. The fact that 'git submodule add' is dependent\non the currently-checked-out branch is a surprise to me.\n\n> When you tried the detached-HEAD scenario, did you get URLs for\n> \"public:git/sub\" or \"origin:git/sub\"? Does \"origin\" just happen to be\n> the remote you want to use in any case?\n\nYes, origin happens to be the remote I want to use. Actually, any of\nthe remotes would be fine with me because in this case I want to push to\nall of them eventually. The scenario I was working on was where I am\ncreating a new repository and new submodules to go in it. All of my\nremotes are clones of my repo collection.\n\ngit remote -v\ngit02 git02:foo/tss.git (fetch)\ngit02 git02:foo/tss.git (push)\norigin public:bar/tss (fetch)\norigin public:bar/tss (push)\n\n> My fundamental point is that \"git submodule add\" seems to do confusing\n> things with relative paths. Maybe all that's needed is to clarify the\n> documentation. I'll post a patch.\n\nI definitely agree that 'submodule add' does confusing and unexpected\nthings. I only got it to work by carefully contriving the exact steps\nrequired to make it work. Editing .gitmodules directly would have been\nmuch simpler.\n\nClarifying the documentation is a good first step. But now that you've\nmade me look at this more closely, I see there is much more to complain\nabout and, hopefully, get fixed.\n\nI've run out of time today, though. I'll follow up with another email\non this thread tomorrow.\n\nThanks for stirring this pot.\n\nPhil\n"},{"id":"172187","messageId":"4E306065.2010002@cisco.com","threadId":"27505","inReplyTo":"4DE660E2.9080500@xiplink.com","subject":"Re: [PATCH] submodule add: improve message when resolving a relative url fails","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-07-27T19:00:53Z","receivedAt":"2011-07-27T19:00:53Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 06/01/2011 11:55 AM, Marc Branchaud wrote:\n> On 11-05-31 06:04 PM, Phil Hord wrote:\n>> On 05/31/2011 04:57 PM, Marc Branchaud wrote:\n>>> - The current code rewrites the URL so that any relative path is either\n>>> rejected or munged into an absolute remote URL.\n>> I don't see the URL getting munged away from being relative. Can you\n>> point to an example?\n> I reached this conclusion because if I go into my clone of git.git and do\n>\n> \tgit submodule add ../MyThing\n>\n> where ../MyThing is a regular git repo, I get\n>\n> Cloning into MyThing...\n> fatal: The remote end hung up unexpectedly\n> Clone of 'git://git.kernel.org/pub/scm/git/MyThing' into submodule path\n> 'MyThing' failed\n>\n> So it seemed the relative URL became an absolute URL.\n>\n> Looking more closely at a working example, I can see that (as you show below)\n> the URL in the super-repo's .gitmodules file retains the relative path, but\n> the submodule's remote.origin.url is an absolute path.\n>\n> In any case, \"submodule add\" isn't doing what I expected: make my local\n> MyThing repo a submodule of my git.git clone.\n\nI thought I understood this workflow better than I actually did. I\nthink I understand more now, and I'm somewhat disappointed. But I also\nfailed to pick up the ball on this old discussion.\n\nIf you do this, I think it will work like you were hoping:\n\n :: ( mkdir MyThing && cd MyThing && git init )\n Initialized empty Git repository in /opc/git/MyThing/.git/\n :: git submodule add ../MyThing\n Adding existing repo at 'MyThing' to the index\n\nI haven't examined the code, but I think this is how it works. 'git\nsubmodule add' takes a URL and a local path. When you omit the local\npath, git infers one from the URL. So these two commands are equivalent:\n :: git submodule add ../MyThing\n :: git submodule add ../MyThing MyThing\n\n\nIf the path you provide (explicitly or implicitly) already contains a\ngit repo, it is assumed to be \"the\" submodule repo and git uses it. If\nit does not contain a git repo, git attempts to clone it from the\n(remote) URL.\n\nFurthermore, the relative path only works for URLs. It does not work\nfor local filesystems.\n\nPhil\n"},{"id":"172357","messageId":"4E33139C.5000209@xiplink.com","threadId":"27505","inReplyTo":"4E306065.2010002@cisco.com","subject":"Re: [PATCH] submodule add: improve message when resolving a relative url fails","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-07-29T20:10:04Z","receivedAt":"2011-07-29T20:10:04Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-07-27 03:00 PM, Phil Hord wrote:\n> On 06/01/2011 11:55 AM, Marc Branchaud wrote:\n>> On 11-05-31 06:04 PM, Phil Hord wrote:\n>>> On 05/31/2011 04:57 PM, Marc Branchaud wrote:\n>>>> - The current code rewrites the URL so that any relative path is either\n>>>> rejected or munged into an absolute remote URL.\n>>> I don't see the URL getting munged away from being relative. Can you\n>>> point to an example?\n>> I reached this conclusion because if I go into my clone of git.git and do\n>>\n>> \tgit submodule add ../MyThing\n>>\n>> where ../MyThing is a regular git repo, I get\n>>\n>> Cloning into MyThing...\n>> fatal: The remote end hung up unexpectedly\n>> Clone of 'git://git.kernel.org/pub/scm/git/MyThing' into submodule path\n>> 'MyThing' failed\n>>\n>> So it seemed the relative URL became an absolute URL.\n>>\n>> Looking more closely at a working example, I can see that (as you show below)\n>> the URL in the super-repo's .gitmodules file retains the relative path, but\n>> the submodule's remote.origin.url is an absolute path.\n>>\n>> In any case, \"submodule add\" isn't doing what I expected: make my local\n>> MyThing repo a submodule of my git.git clone.\n> \n> I thought I understood this workflow better than I actually did. I\n> think I understand more now, and I'm somewhat disappointed. But I also\n> failed to pick up the ball on this old discussion.\n> \n> If you do this, I think it will work like you were hoping:\n> \n> :: ( mkdir MyThing && cd MyThing && git init )\n> Initialized empty Git repository in /opc/git/MyThing/.git/\n> :: git submodule add ../MyThing\n> Adding existing repo at 'MyThing' to the index\n\nI see how that works, but I don't find that intuitive at all. For one,\n../MyThing doesn't even exist, neither locally or on the origin repo. It's\nreally ./MyThing (with one dot). The last idea that I'd come up with for\nadding ./MyThing as a submodule would be to use ../MyThing.\n\nWhat git does in this case actually looks like a bug to me. I'd expect \"git\nsubmodule add ../MyThing\" to fail if there's no local ../MyThing and no\nremote ../MyThing.\n\n> Furthermore, the relative path only works for URLs. It does not work\n> for local filesystems.\n\nWell, sort of. From the current man page: \"If the superproject doesn't have\nan origin configured the superproject is its own authoritative upstream and\nthe current working directory is used instead.\"\n\nI submitted two patches to clarify the documentation on that point:\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/175163\n\thttp://article.gmane.org/gmane.comp.version-control.git/175162\n\nThey seemed to have been lost in the shuffle, though.\n\n\t\tM.\n"}]}