{"thread":{"id":"8560","subject":"[PATCH 0/5] misc. submodule related changes","startedAt":"2007-06-11T19:12:20Z","lastAt":"2007-06-12T21:33:13Z","messageCount":28,"participants":["Lars Hjemli","Frank Lichtenheld","Sven Verdoolaege","Josef Weidendorfer","Johannes Sixt","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"44744","messageId":"11815891453464-git-send-email-hjemli@gmail.com","threadId":"8560","inReplyTo":null,"subject":"[PATCH 0/5] misc. submodule related changes","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-11T19:12:20Z","receivedAt":"2007-06-11T19:12:20Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"Here is a reworked patch-series for git-submodule, trying to cater for\nthe issues with the previous series.\n\nShortlog:\n [1/5] t7400: barf if git-submodule removes or replaces a file\n [2/5] git-submodule: remember to checkout after clone\n [3/5] Rename sections from \"module\" to \"submodule\" in .gitmodules\n [4/5] git-submodule: give submodules proper names\n [5/5] Add gitmodules(5)\n\nDiffstat:\nDocumentation/Makefile       |    2 +-\nDocumentation/gitmodules.txt |   63 ++++++++++++++++++++++++++++++++++++++++++\ngit-submodule.sh             |   52 +++++++++++++++++++++++-----------\nt/t7400-submodule-basic.sh   |   22 +++++++++++---\n4 files changed, 116 insertions(+), 23 deletions(-)\n"},{"id":"44748","messageId":"11815891451258-git-send-email-hjemli@gmail.com","threadId":"8560","inReplyTo":"11815891453464-git-send-email-hjemli@gmail.com","subject":"[PATCH 1/5] t7400: barf if git-submodule removes or replaces a file","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-11T19:12:21Z","receivedAt":"2007-06-11T19:12:21Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"The test for an unmolested file wouldn't fail properly if the file had been\nremoved or replaced by something other than a regular file. This fixes it.\n\nSigned-off-by: Lars Hjemli <hjemli@gmail.com>\n---\n t/t7400-submodule-basic.sh |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex 3940433..74fafce 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -72,7 +72,7 @@ test_expect_success 'update should fail when path is used by a file' '\n \tthen\n \t\techo \"[OOPS] update should have failed\"\n \t\tfalse\n-\telif test -f lib && test \"$(cat lib)\" != \"hello\"\n+\telif test \"$(cat lib)\" != \"hello\"\n \tthen\n \t\techo \"[OOPS] update failed but lib file was molested\"\n \t\tfalse\n-- \n1.5.2.1.914.gbd3a7\n"},{"id":"44745","messageId":"1181589146478-git-send-email-hjemli@gmail.com","threadId":"8560","inReplyTo":"11815891451258-git-send-email-hjemli@gmail.com","subject":"[PATCH 2/5] git-submodule: remember to checkout after clone","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-11T19:12:22Z","receivedAt":"2007-06-11T19:12:22Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"After the initial clone of a submodule, no files would be checked out in\nthe submodule directory if the submodule HEAD was equal to the SHA-1\nspecified in the index of the containing repository. This fixes the problem\nby simply ignoring submodule HEAD for a fresh clone.\n\nSigned-off-by: Lars Hjemli <hjemli@gmail.com>\n---\n git-submodule.sh |    9 +++++----\n 1 files changed, 5 insertions(+), 4 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 8bdd99a..4a6d64d 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -100,12 +100,13 @@ modules_update()\n \t\tif ! test -d \"$path\"/.git\n \t\tthen\n \t\t\tmodule_clone \"$path\" \"$url\" || exit\n+\t\t\tsubsha1=\n+\t\telse\n+\t\t\tsubsha1=$(unset GIT_DIR && cd \"$path\" &&\n+\t\t\t\tgit-rev-parse --verify HEAD) ||\n+\t\t\tdie \"Unable to find current revision of submodule '$path'\"\n \t\tfi\n \n-\t\tsubsha1=$(unset GIT_DIR && cd \"$path\" &&\n-\t\t\tgit-rev-parse --verify HEAD) ||\n-\t\tdie \"Unable to find current revision of submodule '$path'\"\n-\n \t\tif test \"$subsha1\" != \"$sha1\"\n \t\tthen\n \t\t\t(unset GIT_DIR && cd \"$path\" && git-fetch &&\n-- \n1.5.2.1.914.gbd3a7\n"},{"id":"44753","messageId":"1181589146685-git-send-email-hjemli@gmail.com","threadId":"8560","inReplyTo":"1181589146478-git-send-email-hjemli@gmail.com","subject":"[PATCH 3/5] Rename sections from \"module\" to \"submodule\" in .gitmodules","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-11T19:12:23Z","receivedAt":"2007-06-11T19:12:23Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Lars Hjemli\" <hjemli@gmail.com> writes:\n>\n> > Hmm, maybe I should just rename [module] to [submodule] right now? It\n> > would be better forward compatible with the proposed extension, it\n> > would 'harmonize' the section names used in .gitmodules and\n> > .git/config, and it would offer a clean break from what's currently\n> > supported in 'master'.\n>\n> Yes, the difference between '[submodule]' vs '[module]' in\n> .git/config and .gitmodules confused me while looking at your\n> latest patch series.  I am in favor of unifying them.  We would\n> not be breaking any released version if we harmonize them now.\n\nHere it is.\n\nSigned-off-by: Lars Hjemli <hjemli@gmail.com>\n---\n git-submodule.sh           |    2 +-\n t/t7400-submodule-basic.sh |    2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 4a6d64d..6c83c52 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -66,7 +66,7 @@ modules_init()\n \t\turl=$(git-config submodule.\"$path\".url)\n \t\ttest -z \"$url\" || continue\n \n-\t\turl=$(GIT_CONFIG=.gitmodules git-config module.\"$path\".url)\n+\t\turl=$(GIT_CONFIG=.gitmodules git-config submodule.\"$path\".url)\n \t\ttest -z \"$url\" &&\n \t\tdie \"No url found for submodule '$path' in .gitmodules\"\n \ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex 74fafce..9f2d4f9 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -40,7 +40,7 @@ test_expect_success 'Prepare submodule testing' '\n \tgit-add a lib z &&\n \tgit-commit -m \"super commit 1\" &&\n \tmv lib .subrepo &&\n-\tGIT_CONFIG=.gitmodules git-config module.lib.url git://example.com/lib.git\n+\tGIT_CONFIG=.gitmodules git-config submodule.lib.url git://example.com/lib.git\n '\n \n test_expect_success 'status should only print one line' '\n-- \n1.5.2.1.914.gbd3a7\n"},{"id":"44746","messageId":"1181589146188-git-send-email-hjemli@gmail.com","threadId":"8560","inReplyTo":"1181589146685-git-send-email-hjemli@gmail.com","subject":"[PATCH 4/5] git-submodule: give submodules proper names","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-11T19:12:24Z","receivedAt":"2007-06-11T19:12:24Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"This changes the way git-submodule uses .gitmodules: Subsections no longer\nspecify the submodule path, they now specify the submodule name. The\nsubmodule path is found under the new key \"submodule.<name>.path\", which is\na required key.\n\nWith this change a submodule can be moved between different 'checkout paths'\nwithout upsetting git-submodule.\n\nSigned-off-by: Lars Hjemli <hjemli@gmail.com>\n---\n git-submodule.sh           |   45 ++++++++++++++++++++++++++++++-------------\n t/t7400-submodule-basic.sh |   20 +++++++++++++++---\n 2 files changed, 47 insertions(+), 18 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 6c83c52..89a3885 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -25,6 +25,19 @@ say()\n \tfi\n }\n \n+#\n+# Map submodule path to submodule name\n+#\n+# $1 = path\n+#\n+module_name()\n+{\n+       name=$(GIT_CONFIG=.gitmodules git-config --get-regexp '^submodule\\..*\\.path$' \"$1\" |\n+       sed -nre 's/^submodule\\.(.+)\\.path .+$/\\1/p')\n+       test -z \"$name\" &&\n+       die \"No submodule mapping found in .gitmodules for path '$path'\"\n+       echo \"$name\"\n+}\n \n #\n # Clone a submodule\n@@ -49,7 +62,7 @@ module_clone()\n \tdie \"A file already exist at path '$path'\"\n \n \tgit-clone -n \"$url\" \"$path\" ||\n-\tdie \"Clone of submodule '$path' failed\"\n+\tdie \"Clone of '$url' into submodule path '$path' failed\"\n }\n \n #\n@@ -63,17 +76,18 @@ modules_init()\n \twhile read mode sha1 stage path\n \tdo\n \t\t# Skip already registered paths\n-\t\turl=$(git-config submodule.\"$path\".url)\n+\t\tname=$(module_name \"$path\") || exit\n+\t\turl=$(git-config submodule.\"$name\".url)\n \t\ttest -z \"$url\" || continue\n \n-\t\turl=$(GIT_CONFIG=.gitmodules git-config submodule.\"$path\".url)\n+\t\turl=$(GIT_CONFIG=.gitmodules git-config submodule.\"$name\".url)\n \t\ttest -z \"$url\" &&\n-\t\tdie \"No url found for submodule '$path' in .gitmodules\"\n+\t\tdie \"No url found for submodule path '$path' in .gitmodules\"\n \n-\t\tgit-config submodule.\"$path\".url \"$url\" ||\n-\t\tdie \"Failed to register url for submodule '$path'\"\n+\t\tgit-config submodule.\"$name\".url \"$url\" ||\n+\t\tdie \"Failed to register url for submodule path '$path'\"\n \n-\t\tsay \"Submodule '$path' registered with url '$url'\"\n+\t\tsay \"Submodule '$name' ($url) registered for path '$path'\"\n \tdone\n }\n \n@@ -87,13 +101,14 @@ modules_update()\n \tgit ls-files --stage -- \"$@\" | grep -e '^160000 ' |\n \twhile read mode sha1 stage path\n \tdo\n-\t\turl=$(git-config submodule.\"$path\".url)\n+\t\tname=$(module_name \"$path\") || exit\n+\t\turl=$(git-config submodule.\"$name\".url)\n \t\tif test -z \"$url\"\n \t\tthen\n \t\t\t# Only mention uninitialized submodules when its\n \t\t\t# path have been specified\n \t\t\ttest \"$#\" != \"0\" &&\n-\t\t\tsay \"Submodule '$path' not initialized\"\n+\t\t\tsay \"Submodule path '$path' not initialized\"\n \t\t\tcontinue\n \t\tfi\n \n@@ -104,22 +119,22 @@ modules_update()\n \t\telse\n \t\t\tsubsha1=$(unset GIT_DIR && cd \"$path\" &&\n \t\t\t\tgit-rev-parse --verify HEAD) ||\n-\t\t\tdie \"Unable to find current revision of submodule '$path'\"\n+\t\t\tdie \"Unable to find current revision in submodule path '$path'\"\n \t\tfi\n \n \t\tif test \"$subsha1\" != \"$sha1\"\n \t\tthen\n \t\t\t(unset GIT_DIR && cd \"$path\" && git-fetch &&\n \t\t\t\tgit-checkout -q \"$sha1\") ||\n-\t\t\tdie \"Unable to checkout '$sha1' in submodule '$path'\"\n+\t\t\tdie \"Unable to checkout '$sha1' in submodule path '$path'\"\n \n-\t\t\tsay \"Submodule '$path': checked out '$sha1'\"\n+\t\t\tsay \"Submodule path '$path': checked out '$sha1'\"\n \t\tfi\n \tdone\n }\n \n #\n-# List all registered submodules, prefixed with:\n+# List all submodules, prefixed with:\n #  - submodule not initialized\n #  + different revision checked out\n #\n@@ -133,7 +148,9 @@ modules_list()\n \tgit ls-files --stage -- \"$@\" | grep -e '^160000 ' |\n \twhile read mode sha1 stage path\n \tdo\n-\t\tif ! test -d \"$path\"/.git\n+\t\tname=$(module_name \"$path\") || exit\n+\t\turl=$(git-config submodule.\"$name\".url)\n+\t\tif test -z \"url\" || ! test -d \"$path\"/.git\n \t\tthen\n \t\t\tsay \"-$sha1 $path\"\n \t\t\tcontinue;\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex 9f2d4f9..7a9b505 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -18,7 +18,7 @@ subcommands of git-submodule.\n #  -add directory lib to 'superproject', this creates a DIRLINK entry\n #  -add a couple of regular files to enable testing of submodule filtering\n #  -mv lib subrepo\n-#  -add an entry to .gitmodules for path 'lib'\n+#  -add an entry to .gitmodules for submodule 'example'\n #\n test_expect_success 'Prepare submodule testing' '\n \tmkdir lib &&\n@@ -40,7 +40,19 @@ test_expect_success 'Prepare submodule testing' '\n \tgit-add a lib z &&\n \tgit-commit -m \"super commit 1\" &&\n \tmv lib .subrepo &&\n-\tGIT_CONFIG=.gitmodules git-config submodule.lib.url git://example.com/lib.git\n+\tGIT_CONFIG=.gitmodules git-config submodule.example.url git://example.com/lib.git\n+'\n+\n+test_expect_success 'status should fail for unmapped paths' '\n+\tif git-submodule status\n+\tthen\n+\t\techo \"[OOPS] submodule status succeeded\"\n+\t\tfalse\n+\telif ! GIT_CONFIG=.gitmodules git-config submodule.example.path lib\n+\tthen\n+\t\techo \"[OOPS] git-config failed to update .gitmodules\"\n+\t\tfalse\n+\tfi\n '\n \n test_expect_success 'status should only print one line' '\n@@ -54,12 +66,12 @@ test_expect_success 'status should initially be \"missing\"' '\n \n test_expect_success 'init should register submodule url in .git/config' '\n \tgit-submodule init &&\n-\turl=$(git-config submodule.lib.url) &&\n+\turl=$(git-config submodule.example.url) &&\n \tif test \"$url\" != \"git://example.com/lib.git\"\n \tthen\n \t\techo \"[OOPS] init succeeded but submodule url is wrong\"\n \t\tfalse\n-\telif ! git-config submodule.lib.url ./.subrepo\n+\telif ! git-config submodule.example.url ./.subrepo\n \tthen\n \t\techo \"[OOPS] init succeeded but update of url failed\"\n \t\tfalse\n-- \n1.5.2.1.914.gbd3a7\n"},{"id":"44747","messageId":"11815891463922-git-send-email-hjemli@gmail.com","threadId":"8560","inReplyTo":"1181589146188-git-send-email-hjemli@gmail.com","subject":"[PATCH 5/5] Add gitmodules(5)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-11T19:12:25Z","receivedAt":"2007-06-11T19:12:25Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"This adds documentation for the .gitmodules file.\n\nSigned-off-by: Lars Hjemli <hjemli@gmail.com>\n---\n Documentation/Makefile       |    2 +-\n Documentation/gitmodules.txt |   62 ++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 63 insertions(+), 1 deletions(-)\n create mode 100644 Documentation/gitmodules.txt\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 9cef480..2ad18e0 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -2,7 +2,7 @@ MAN1_TXT= \\\n \t$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \\\n \t\t$(wildcard git-*.txt)) \\\n \tgitk.txt\n-MAN5_TXT=gitattributes.txt gitignore.txt\n+MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt\n MAN7_TXT=git.txt\n \n DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nnew file mode 100644\nindex 0000000..6c7d9bf\n--- /dev/null\n+++ b/Documentation/gitmodules.txt\n@@ -0,0 +1,62 @@\n+gitmodules(5)\n+=============\n+\n+NAME\n+----\n+gitmodules - defining submodule properties\n+\n+SYNOPSIS\n+--------\n+.gitmodules\n+\n+\n+DESCRIPTION\n+-----------\n+\n+The `.gitmodules` file, located in the top-level directory of a git\n+working tree, is a text file with a syntax matching the requirements\n+of gitlink:git-config[1].\n+\n+The file contains one subsection per submodule, and the subsection value\n+is the name of the submodule. Each submodule section also contains the\n+following required keys:\n+\n+submodule.<name>.path::\n+\tDefines the path, relative to the top-level directory of the git\n+\tworking tree, where the submodule is expected to be checked out.\n+\tThe path name must not end with a `/`. All submodule paths must\n+\tbe unique within the .gitmodules file.\n+\n+submodule.<name>.url::\n+\tDefines an url from where the submodule repository can be cloned.\n+\n+\n+EXAMPLES\n+--------\n+\n+Consider the following .gitmodules file:\n+\n+\t[submodule 'libfoo']\n+\t\tpath = include/foo\n+\t\turl = git://foo.com/git/lib.git\n+\n+\t[submodule 'libbar']\n+\t\tpath = include/bar\n+\t\turl = git://bar.com/git/lib.git\n+\n+\n+This defines two submodules, `libfoo` and `libbar`. These are expected to\n+be checked out in the paths 'include/foo' and 'include/bar', and for both\n+submodules an url is specified which can be used for cloning the submodules.\n+\n+SEE ALSO\n+--------\n+gitlink:git-submodule[1] gitlink:git-config[1]\n+\n+DOCUMENTATION\n+-------------\n+Documentation by Lars Hjemli <hjemli@gmail.com>\n+\n+GIT\n+---\n+Part of the gitlink:git[7] suite\n-- \n1.5.2.1.914.gbd3a7\n"},{"id":"44768","messageId":"20070611225918.GD4323@planck.djpig.de","threadId":"8560","inReplyTo":"11815891463922-git-send-email-hjemli@gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Frank Lichtenheld","fromEmail":"frank@lichtenheld.de","sentAt":"2007-06-11T22:59:19Z","receivedAt":"2007-06-11T22:59:19Z","isPatch":true,"sender":{"key":"frank@lichtenheld.de","avatar":"https://gravatar.com/avatar/b9f1d4b120e138f157c9e480d0818197c474628923786adb98f30017cdb99c3c?d=mp&s=160"},"body":"On Mon, Jun 11, 2007 at 09:12:25PM +0200, Lars Hjemli wrote:\n> +Consider the following .gitmodules file:\n> +\n> +\t[submodule 'libfoo']\n> +\t\tpath = include/foo\n> +\t\turl = git://foo.com/git/lib.git\n> +\n> +\t[submodule 'libbar']\n> +\t\tpath = include/bar\n> +\t\turl = git://bar.com/git/lib.git\n> +\n\nStill the wrong quotes.\n\nGruesse,\n-- \nFrank Lichtenheld <frank@lichtenheld.de>\nwww: http://www.djpig.de/\n"},{"id":"44802","messageId":"11816319211097-git-send-email-hjemli@gmail.com","threadId":"8560","inReplyTo":"20070611225918.GD4323@planck.djpig.de","subject":"[PATCH 5/5] Add gitmodules(5)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-12T07:05:21Z","receivedAt":"2007-06-12T07:05:21Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"This adds documentation for the .gitmodules file.\n\nSigned-off-by: Lars Hjemli <hjemli@gmail.com>\n---\n\nOn 6/12/07, Frank Lichtenheld <frank@lichtenheld.de> wrote:\n> On Mon, Jun 11, 2007 at 09:12:25PM +0200, Lars Hjemli wrote:\n> > +Consider the following .gitmodules file:\n> > +\n> > +     [submodule 'libfoo']\n> > +             path = include/foo\n> > +             url = git://foo.com/git/lib.git\n> > +\n> > +     [submodule 'libbar']\n> > +             path = include/bar\n> > +             url = git://bar.com/git/lib.git\n> > +\n> \n> Still the wrong quotes.\n\nThanks for noticing\n\n\n Documentation/Makefile       |    2 +-\n Documentation/gitmodules.txt |   62 ++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 63 insertions(+), 1 deletions(-)\n create mode 100644 Documentation/gitmodules.txt\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 9cef480..2ad18e0 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -2,7 +2,7 @@ MAN1_TXT= \\\n \t$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \\\n \t\t$(wildcard git-*.txt)) \\\n \tgitk.txt\n-MAN5_TXT=gitattributes.txt gitignore.txt\n+MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt\n MAN7_TXT=git.txt\n \n DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nnew file mode 100644\nindex 0000000..6c7d9bf\n--- /dev/null\n+++ b/Documentation/gitmodules.txt\n@@ -0,0 +1,62 @@\n+gitmodules(5)\n+=============\n+\n+NAME\n+----\n+gitmodules - defining submodule properties\n+\n+SYNOPSIS\n+--------\n+.gitmodules\n+\n+\n+DESCRIPTION\n+-----------\n+\n+The `.gitmodules` file, located in the top-level directory of a git\n+working tree, is a text file with a syntax matching the requirements\n+of gitlink:git-config[1].\n+\n+The file contains one subsection per submodule, and the subsection value\n+is the name of the submodule. Each submodule section also contains the\n+following required keys:\n+\n+submodule.<name>.path::\n+\tDefines the path, relative to the top-level directory of the git\n+\tworking tree, where the submodule is expected to be checked out.\n+\tThe path name must not end with a `/`. All submodule paths must\n+\tbe unique within the .gitmodules file.\n+\n+submodule.<name>.url::\n+\tDefines an url from where the submodule repository can be cloned.\n+\n+\n+EXAMPLES\n+--------\n+\n+Consider the following .gitmodules file:\n+\n+\t[submodule \"libfoo\"]\n+\t\tpath = include/foo\n+\t\turl = git://foo.com/git/lib.git\n+\n+\t[submodule \"libbar\"]\n+\t\tpath = include/bar\n+\t\turl = git://bar.com/git/lib.git\n+\n+\n+This defines two submodules, `libfoo` and `libbar`. These are expected to\n+be checked out in the paths 'include/foo' and 'include/bar', and for both\n+submodules an url is specified which can be used for cloning the submodules.\n+\n+SEE ALSO\n+--------\n+gitlink:git-submodule[1] gitlink:git-config[1]\n+\n+DOCUMENTATION\n+-------------\n+Documentation by Lars Hjemli <hjemli@gmail.com>\n+\n+GIT\n+---\n+Part of the gitlink:git[7] suite\n-- \n1.5.2.1.914.gbd3a7\n"},{"id":"44806","messageId":"20070612080402.GQ955MdfPADPa@greensroom.kotnet.org","threadId":"8560","inReplyTo":"11816319211097-git-send-email-hjemli@gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-06-12T08:04:02Z","receivedAt":"2007-06-12T08:04:02Z","isPatch":true,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Tue, Jun 12, 2007 at 09:05:21AM +0200, Lars Hjemli wrote:\n> +The file contains one subsection per submodule, and the subsection value\n> +is the name of the submodule. Each submodule section also contains the\n> +following required keys:\n\nYour only argument for making them required was that Junio thought that\nnot having them might be ambiguous, but he doesn't think so anymore.\n\n> +submodule.<name>.path::\n> +\tDefines the path, relative to the top-level directory of the git\n\nYour previous patch had \"_a_ path\" instead of \"_the_ path\".\nI prefer the former since it allows a module to be checkoud out\nat multiple locations.\n\nskimo\n"},{"id":"44808","messageId":"8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com","threadId":"8560","inReplyTo":"20070612080402.GQ955MdfPADPa@greensroom.kotnet.org","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-12T08:27:00Z","receivedAt":"2007-06-12T08:27:00Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:\n> On Tue, Jun 12, 2007 at 09:05:21AM +0200, Lars Hjemli wrote:\n> > +The file contains one subsection per submodule, and the subsection value\n> > +is the name of the submodule. Each submodule section also contains the\n> > +following required keys:\n>\n> Your only argument for making them required was that Junio thought that\n> not having them might be ambiguous, but he doesn't think so anymore.\n\nWell, I actually also had an argument about being strict in the\nbeginning and possibly loosen the rules later on. Anyways, I can do a\npatch on top of this series (if/when it's accepted) and let Junio\ndecide to apply or drop the 'optional path' stuff.\n\n>\n> > +submodule.<name>.path::\n> > +     Defines the path, relative to the top-level directory of the git\n>\n> Your previous patch had \"_a_ path\" instead of \"_the_ path\".\n> I prefer the former since it allows a module to be checkoud out\n> at multiple locations.\n\nThis is somewhat intentional. I want to move the submodule repos into\n.git/submodules/$name/ (with working dir) and symlink this directory\nwhen 'checking out' the submodule. This would be a simple solution for\nthe following problems:\n  -keeping submodule modifications between checkouts\n  -having submodules within submodules\n\nMultiple checkout paths for a single submodule will bring havoc on\nthis plan, so I need to ask: what is the use-case for multiple\ncheckout paths?\n\n-- \nlarsh\n"},{"id":"44813","messageId":"200706121145.22699.Josef.Weidendorfer@gmx.de","threadId":"8560","inReplyTo":"8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-06-12T09:45:22Z","receivedAt":"2007-06-12T09:45:22Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 12 June 2007, Lars Hjemli wrote:\n> This is somewhat intentional. I want to move the submodule repos into\n> .git/submodules/$name/ (with working dir) and symlink this directory\n> when 'checking out' the submodule. This would be a simple solution for\n> the following problems:\n>   -keeping submodule modifications between checkouts\n>   -having submodules within submodules\n\nInteresting idea.\n\nHow does this work\n(1) if the submodule checkout changes with the supermodule checkout?\nYou still would have to store the modifications somewhere.\n(2) on platforms which do not allow symlinks\n\nA workaround for problem (1) would be to create multiple checkouts of the\nsame submodule if modified, e.g. in .git/submodule/$name/$sha1 .\n \nAllowing people to work like that is nice, but it should not be forced.\nIt would also be nice to allow the user to specify another place where\nsubmodule checkouts are to be stored, e.g. when multiple supermodules\nshare the same submodule.\n\nJosef\n\n> \n> Multiple checkout paths for a single submodule will bring havoc on\n> this plan, so I need to ask: what is the use-case for multiple\n> checkout paths?\n> \n"},{"id":"44814","messageId":"20070612094931.GR955MdfPADPa@greensroom.kotnet.org","threadId":"8560","inReplyTo":"8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-06-12T09:49:31Z","receivedAt":"2007-06-12T09:49:31Z","isPatch":true,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Tue, Jun 12, 2007 at 10:27:00AM +0200, Lars Hjemli wrote:\n> On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:\n> >Your previous patch had \"_a_ path\" instead of \"_the_ path\".\n> >I prefer the former since it allows a module to be checkoud out\n> >at multiple locations.\n> \n> This is somewhat intentional. I want to move the submodule repos into\n> .git/submodules/$name/ (with working dir) and symlink this directory\n\nI had that in my patch series, but I got a complaint that symlinks\ndon't work on Windows.\n\n> Multiple checkout paths for a single submodule will bring havoc on\n> this plan, so I need to ask: what is the use-case for multiple\n> checkout paths?\n\nThe case where you need two different versions of the same\nsubmodule in one (presumably big) project.\n(Not that I need that just now.)\n\nskimo\n"},{"id":"44815","messageId":"8c5c35580706120323t52b0d095v6ab6013ee2c8fdea@mail.gmail.com","threadId":"8560","inReplyTo":"200706121145.22699.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-12T10:23:20Z","receivedAt":"2007-06-12T10:23:20Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 6/12/07, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> On Tuesday 12 June 2007, Lars Hjemli wrote:\n> > This is somewhat intentional. I want to move the submodule repos into\n> > .git/submodules/$name/ (with working dir) and symlink this directory\n> > when 'checking out' the submodule. This would be a simple solution for\n> > the following problems:\n> >   -keeping submodule modifications between checkouts\n> >   -having submodules within submodules\n>\n> Interesting idea.\n>\n> How does this work\n> (1) if the submodule checkout changes with the supermodule checkout?\n> You still would have to store the modifications somewhere.\n\nIf you're thinking about the detached HEAD: yeah, that's a problem. My\ninitial plan (with later modifications) was something like this:\n\n[path \"lib1\"]\n  submodule=lib\n  branch=stable\n\n[path \"lib2\"]\n  submodule=lib\n  branch=bleeding\n\n[submodule \"lib\"]\n  url=git://example.com/lib.git\n\n$ git-submodule init\n  git-config submodule.lib.url git://example.com/lib.git\n\n$ git-submodule update\n  git-clone --bare git://example.com/lib.git .git/submodules/lib.git\n  git-clone -l -s -n .git/submodules/lib.git lib1\n  (cd lib1 && git-checkout $sha1)\n  git-clone -l -s -n .git/submodules/lib.git lib2\n  (cd lib2 && git-checkout $sha2)\n\ngit-submodule push:\n  (cd lib1 && git-push origin $branch1)\n  (cd lib2 && git-push origin $branch2)\n\nI thought I could avoid 'git-submodule push' by using symlinks, but\nyou're right. It will not work. Back to the drawing board (again...)\n\n\n> (2) on platforms which do not allow symlinks\n\nOk, bad idea.\n\n\n>\n> A workaround for problem (1) would be to create multiple checkouts of the\n> same submodule if modified, e.g. in .git/submodule/$name/$sha1 .\n\nAnd the $sha1 would be the sha1 found in the index? I don't think this\nwould work either. If two branches in the superproject checkout the\nsame submodule sha1, you could possibly want to keep different changes\nin the submodule depending on which branch of the superproject is\nchecked out.\n\nI guess the user will have to both commit and push submodule changes\nbefore switching branches etc. But that might not be too bad, at least\nfor the initial submodule support.\n\n>\n> Allowing people to work like that is nice, but it should not be forced.\n> It would also be nice to allow the user to specify another place where\n> submodule checkouts are to be stored, e.g. when multiple supermodules\n> share the same submodule.\n\nTrue. Maybe submodule.<name>.repopath in .git/config? (If not\nspecified, default to .git/submodules/<name>.git)\n\n--\nlarsh\n"},{"id":"44816","messageId":"8c5c35580706120328s5829ed08u85fb0838262d83fd@mail.gmail.com","threadId":"8560","inReplyTo":"20070612094931.GR955MdfPADPa@greensroom.kotnet.org","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-12T10:28:13Z","receivedAt":"2007-06-12T10:28:13Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:\n> On Tue, Jun 12, 2007 at 10:27:00AM +0200, Lars Hjemli wrote:\n> > On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:\n> > >Your previous patch had \"_a_ path\" instead of \"_the_ path\".\n> > >I prefer the former since it allows a module to be checkoud out\n> > >at multiple locations.\n> >\n> > This is somewhat intentional. I want to move the submodule repos into\n> > .git/submodules/$name/ (with working dir) and symlink this directory\n>\n> I had that in my patch series, but I got a complaint that symlinks\n> don't work on Windows.\n\nYeah, I didn't consider windows.\n\n>\n> > Multiple checkout paths for a single submodule will bring havoc on\n> > this plan, so I need to ask: what is the use-case for multiple\n> > checkout paths?\n>\n> The case where you need two different versions of the same\n> submodule in one (presumably big) project.\n\nLet me rephrase: why would anyone need to checkout two different\nversions of the same submodule simultaneously inside a single\nsuperproject?\n\n-- \nlarsh\n"},{"id":"44817","messageId":"466E76BE.A3F84A2D@eudaptics.com","threadId":"8560","inReplyTo":"8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-12T10:34:38Z","receivedAt":"2007-06-12T10:34:38Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Lars Hjemli wrote:\n> \n> On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:\n> > On Tue, Jun 12, 2007 at 09:05:21AM +0200, Lars Hjemli wrote:\n> > > +submodule.<name>.path::\n> > > +     Defines the path, relative to the top-level directory of the git\n> >\n> > Your previous patch had \"_a_ path\" instead of \"_the_ path\".\n> > I prefer the former since it allows a module to be checkoud out\n> > at multiple locations.\n> \n> This is somewhat intentional. I want to move the submodule repos into\n> .git/submodules/$name/ (with working dir) and symlink this directory\n> when 'checking out' the submodule. This would be a simple solution for\n> the following problems:\n>   -keeping submodule modifications between checkouts\n>   -having submodules within submodules\n\nIt has already been said in the past that symlinks are *bad*. The don't\nexist on Windows (MinGW). Please do not use symlinks for such central\nconcepts.\n\n-- Hannes\n"},{"id":"44818","messageId":"466E7A17.CEB0F196@eudaptics.com","threadId":"8560","inReplyTo":"8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-12T10:48:55Z","receivedAt":"2007-06-12T10:48:55Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Lars Hjemli wrote:\n> Multiple checkout paths for a single submodule will bring havoc on\n> this plan, so I need to ask: what is the use-case for multiple\n> checkout paths?\n\nA use-case is the admin directory in the KDE repository. It has:\n\nKDE (superproject)\n +- kdelibs (subproject)\n |   +- admin (subproject)\n |   +- subdir1\n |   +- ...\n +- kdebase (subproject)\n |   +- admin (subproject)\n |   +- subdir2\n |   +- ...\n +- kdenetwork (subproject)\n |   +- admin (subproject)\n |   +- subdir3\n |   +- ...\n ...\n\n-- Hannes\n"},{"id":"44819","messageId":"8c5c35580706120354w69bddb7o8edce484be714087@mail.gmail.com","threadId":"8560","inReplyTo":"8c5c35580706120352y24e53a10sf339147b22f1286e@mail.gmail.com","subject":"[PATCH 5/5] Add gitmodules(5)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-12T10:54:31Z","receivedAt":"2007-06-12T10:54:31Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"(readded the gitlist)\n\nOn 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:\n> Lars Hjemli wrote:\n> > Multiple checkout paths for a single submodule will bring havoc on\n> > this plan, so I need to ask: what is the use-case for multiple\n> > checkout paths?\n>\n> A use-case is the admin directory in the KDE repository. It has:\n>\n> KDE (superproject)\n>  +- kdelibs (subproject)\n>  |   +- admin (subproject)\n>  |   +- subdir1\n>  |   +- ...\n>  +- kdebase (subproject)\n>  |   +- admin (subproject)\n>  |   +- subdir2\n>  |   +- ...\n>  +- kdenetwork (subproject)\n>  |   +- admin (subproject)\n>  |   +- subdir3\n>  |   +- ...\n>  ...\n\nBut in this case, 'admin' isn't a submodule/subproject contained by\nKDE, right? It's contained in three different submodules/subprojects:\nkdelibs, kdebase and kdenetwork.\n\n--\nlarsh\n"},{"id":"44820","messageId":"466E7D7E.7BAB2FD@eudaptics.com","threadId":"8560","inReplyTo":"8c5c35580706120352y24e53a10sf339147b22f1286e@mail.gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-12T11:03:26Z","receivedAt":"2007-06-12T11:03:26Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Lars Hjemli wrote:\n> \n> (readded the gitlist)\n> \n> On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:\n> > Lars Hjemli wrote:\n> > > Multiple checkout paths for a single submodule will bring havoc on\n> > > this plan, so I need to ask: what is the use-case for multiple\n> > > checkout paths?\n> >\n> > A use-case is the admin directory in the KDE repository. It has:\n> >\n> > KDE (superproject)\n> >  +- kdelibs (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir1\n> >  |   +- ...\n> >  +- kdebase (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir2\n> >  |   +- ...\n> >  +- kdenetwork (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir3\n> >  |   +- ...\n> >  ...\n> \n> But in this case, 'admin' isn't a submodule/subproject contained by\n> KDE, right? It's contained in three different submodules/subprojects:\n> kdelibs, kdebase and kdenetwork.\n\nNotice how kdelibs, kdebase and kdenetwork are both submodule and\nsupermodule: They host the submodule admin and are hosted by KDE.\n\n(If I missed the point, then it's because I didn't follow the\ndiscussion; I jumped in because I noticed the symlink proposal by\nchance.)\n\n-- Hannes\n"},{"id":"44821","messageId":"8c5c35580706120412o516ec39p71332d23823d7389@mail.gmail.com","threadId":"8560","inReplyTo":"466E7D7E.7BAB2FD@eudaptics.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-12T11:12:07Z","receivedAt":"2007-06-12T11:12:07Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:\n> Lars Hjemli wrote:\n> >\n> > (readded the gitlist)\n> >\n> > On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:\n> > > Lars Hjemli wrote:\n> > > > Multiple checkout paths for a single submodule will bring havoc on\n> > > > this plan, so I need to ask: what is the use-case for multiple\n> > > > checkout paths?\n> > >\n> > > A use-case is the admin directory in the KDE repository. It has:\n> > >\n> > > KDE (superproject)\n> > >  +- kdelibs (subproject)\n> > >  |   +- admin (subproject)\n> > >  |   +- subdir1\n> > >  |   +- ...\n> > >  +- kdebase (subproject)\n> > >  |   +- admin (subproject)\n> > >  |   +- subdir2\n> > >  |   +- ...\n> > >  +- kdenetwork (subproject)\n> > >  |   +- admin (subproject)\n> > >  |   +- subdir3\n> > >  |   +- ...\n> > >  ...\n> >\n> > But in this case, 'admin' isn't a submodule/subproject contained by\n> > KDE, right? It's contained in three different submodules/subprojects:\n> > kdelibs, kdebase and kdenetwork.\n>\n> Notice how kdelibs, kdebase and kdenetwork are both submodule and\n> supermodule: They host the submodule admin and are hosted by KDE.\n>\n\nExactly my point ;-)\n\n> (If I missed the point, then it's because I didn't follow the\n> discussion; I jumped in because I noticed the symlink proposal by\n> chance.)\n\nIn this case, I would assume that e.g. kdelibs contain a submodule\nentry for path admin in its index, accompanied by a .gitmodules file\nsaying that the path admin is mapped to this or that submodule. I\nwould not expect the KDE 'supersuperproject' to know about admin at\nall, neither in its index nor .gitmodules.\n\n--\nlarsh\n"},{"id":"44824","messageId":"200706121405.08357.Josef.Weidendorfer@gmx.de","threadId":"8560","inReplyTo":"8c5c35580706120323t52b0d095v6ab6013ee2c8fdea@mail.gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-06-12T12:05:08Z","receivedAt":"2007-06-12T12:05:08Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 12 June 2007, Lars Hjemli wrote:\n> If you're thinking about the detached HEAD: yeah, that's a problem. My\n> initial plan (with later modifications) was something like this:\n> \n> ...\n> \n> $ git-submodule update\n>   git-clone --bare git://example.com/lib.git .git/submodules/lib.git\n>   git-clone -l -s -n .git/submodules/lib.git lib1\n>   (cd lib1 && git-checkout $sha1)\n>   git-clone -l -s -n .git/submodules/lib.git lib2\n>   (cd lib2 && git-checkout $sha2)\n> ...\n\nThat looks fine to me.\n \n> git-submodule push:\n>   (cd lib1 && git-push origin $branch1)\n>   (cd lib2 && git-push origin $branch2)\n\nThis could be problematic. You are only storing changes on the\ngiven branch. Ah, you wanted to avoid this problem with the symlink?\n\nPerhaps we need better support for \"push all reachable objects\nwhich are not on the remote side together with any branch tip changes\".\nOr is this somehow already available with git-push?\n\nOr ...\n\n> I thought I could avoid 'git-submodule push' by using symlinks, but\n> you're right. It will not work. Back to the drawing board (again...)\n\n... we revive the \"lightweight checkout\" idea: share everything\nbut index and HEAD with a given repository. Similar to\n\"contrib/workdir/git-new-workdir\" but witt support in git-core\nto avoid the need for symlinks.\n\n> > A workaround for problem (1) would be to create multiple checkouts of the\n> > same submodule if modified, e.g. in .git/submodule/$name/$sha1 .\n> \n> And the $sha1 would be the sha1 found in the index? I don't think this\n> would work either. If two branches in the superproject checkout the\n> same submodule sha1, you could possibly want to keep different changes\n> in the submodule depending on which branch of the superproject is\n> checked out.\n\nOK, does not work.\n\n> > Allowing people to work like that is nice, but it should not be forced.\n> > It would also be nice to allow the user to specify another place where\n> > submodule checkouts are to be stored, e.g. when multiple supermodules\n> > share the same submodule.\n> \n> True. Maybe submodule.<name>.repopath in .git/config? (If not\n> specified, default to .git/submodules/<name>.git)\n\nSounds good. However, can be done later.\n\nJosef\n\n> \n> --\n> larsh\n>\n"},{"id":"44828","messageId":"200706121423.02127.Josef.Weidendorfer@gmx.de","threadId":"8560","inReplyTo":"8c5c35580706120412o516ec39p71332d23823d7389@mail.gmail.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-06-12T12:23:01Z","receivedAt":"2007-06-12T12:23:01Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 12 June 2007, Lars Hjemli wrote:\n> On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:\n\n> > > > KDE (superproject)\n> > > >  +- kdelibs (subproject)\n> > > >  |   +- admin (subproject)\n> > > >  |   +- subdir1\n> > > >  |   +- ...\n> > > >  +- kdebase (subproject)\n> > > >  |   +- admin (subproject)\n> > > >  |   +- subdir2\n> > > >  |   +- ...\n> > > >  +- kdenetwork (subproject)\n> > > >  |   +- admin (subproject)\n> > > >  |   +- subdir3\n> > > >  |   +- ...\n> > > >  ...\n> \n> In this case, I would assume that e.g. kdelibs contain a submodule\n> entry for path admin in its index, accompanied by a .gitmodules file\n> saying that the path admin is mapped to this or that submodule.\n\nExactly. That's just the \"submodule\" in \"submodule\" case we should\nsupport, too.\n\n> I \n> would not expect the KDE 'supersuperproject' to know about admin at\n> all, neither in its index nor .gitmodules.\n\nThe admin submodule contains KDE specific things. So of course it\nalso would be a submodule in the grand whole KDE superduper module.\nBut that does not really matter.\n\nHowever, to not have a lot of copies of the admin submodule\nin\n\n .git/submodule/admin\n .git/submodule/kdelibs/.git/submodule/admin\n .git/submodule/kdebase/.git/submodule/admin\n .git/submodule/kdenetwork/.git/submodule/admin\n\nthe just suggested submodule.<name>.repopath to specify a repository\noutside of .git/submodule to be shared by kdelibs,kdebase,... would\nbe fine.\n\nJosef\n"},{"id":"44829","messageId":"8c5c35580706120537y75d7a58esd59bf20b6c4dec6f@mail.gmail.com","threadId":"8560","inReplyTo":"200706121423.02127.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-06-12T12:37:25Z","receivedAt":"2007-06-12T12:37:25Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 6/12/07, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:\n> On Tuesday 12 June 2007, Lars Hjemli wrote:\n> > I\n> > would not expect the KDE 'supersuperproject' to know about admin at\n> > all, neither in its index nor .gitmodules.\n>\n> The admin submodule contains KDE specific things. So of course it\n> also would be a submodule in the grand whole KDE superduper module.\n\nAha! But as you say:\n\n> But that does not really matter.\n\nExactly.\n\n>\n> However, to not have a lot of copies of the admin submodule\n> in\n>\n>  .git/submodule/admin\n>  .git/submodule/kdelibs/.git/submodule/admin\n>  .git/submodule/kdebase/.git/submodule/admin\n>  .git/submodule/kdenetwork/.git/submodule/admin\n>\n> the just suggested submodule.<name>.repopath to specify a repository\n> outside of .git/submodule to be shared by kdelibs,kdebase,... would\n> be fine.\n\nYes, repopath would work out nice for KDE (which btw seems to be a\ngreat test-case for git-submodule)\n\n--\nlarsh\n"},{"id":"44830","messageId":"466E9469.5D6BD391@eudaptics.com","threadId":"8560","inReplyTo":"200706121423.02127.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-12T12:41:13Z","receivedAt":"2007-06-12T12:41:13Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Josef Weidendorfer wrote:\n> However, to not have a lot of copies of the admin submodule\n> in\n> \n>  .git/submodule/admin\n>  .git/submodule/kdelibs/.git/submodule/admin\n>  .git/submodule/kdebase/.git/submodule/admin\n>  .git/submodule/kdenetwork/.git/submodule/admin\n> \n> the just suggested submodule.<name>.repopath to specify a repository\n> outside of .git/submodule to be shared by kdelibs,kdebase,... would\n> be fine.\n\nThis clearly shows that having the repositories of submodules in\n.git/submodule does not buy you enough to avoid duplication.\n\n(I don't see enough reason to place a repo for submodule X in project Y\noutside its \"natural\" checked-out directory in project Y. But then, I\nhaven't followed the discussion. Please ignore me if above layout choice\nis for more than just avoiding duplication.)\n\n-- Hannes\n"},{"id":"44833","messageId":"200706121540.52753.Josef.Weidendorfer@gmx.de","threadId":"8560","inReplyTo":"466E9469.5D6BD391@eudaptics.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-06-12T13:40:52Z","receivedAt":"2007-06-12T13:40:52Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 12 June 2007, Johannes Sixt wrote:\n> Josef Weidendorfer wrote:\n> > However, to not have a lot of copies of the admin submodule\n> > in\n> > \n> >  .git/submodule/admin\n> >  .git/submodule/kdelibs/.git/submodule/admin\n> >  .git/submodule/kdebase/.git/submodule/admin\n> >  .git/submodule/kdenetwork/.git/submodule/admin\n> > \n> > the just suggested submodule.<name>.repopath to specify a repository\n> > outside of .git/submodule to be shared by kdelibs,kdebase,... would\n> > be fine.\n> \n> This clearly shows that having the repositories of submodules in\n> .git/submodule does not buy you enough to avoid duplication.\n\nThe .git/submodule space for sure is not flexible enough for all\npossible use cases of submodules (as with KDE repo).\nHowever, as default it seems fine to me.\n\nIMHO sharing of the admin submodule repository should even be possible\nif I have a clone of kdelibs and kdebase independent of the big\nKDE superproject.\n\nIt would be nice to allow submodule.<name>.repopath configs globally\nin ~/.gitconfig, and cloning kdelibs should automatically do the\nright thing, ie. use the already available admin repo for the kdelibs\nclone.\n\n> (I don't see enough reason to place a repo for submodule X in project Y\n> outside its \"natural\" checked-out directory in project Y. But then, I\n> haven't followed the discussion.\n\nTo easily share the objects, branches and local modifications?\n\nCurrently a clone of a superproject always does a full copy of\nany submodule databases because it is independent from any other\nlocal git repository; in the KDE case you would get >4 admin copiess\nif recursive cloning of submodules inside of submodules does that.\n\nJosef\n"},{"id":"44834","messageId":"200706121550.28226.Josef.Weidendorfer@gmx.de","threadId":"8560","inReplyTo":"200706121540.52753.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-06-12T13:50:27Z","receivedAt":"2007-06-12T13:50:27Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 12 June 2007, Josef Weidendorfer wrote:\n> IMHO sharing of the admin submodule repository should even be possible\n> if I have a clone of kdelibs and kdebase independent of the big\n> KDE superproject.\n> \n> It would be nice to allow submodule.<name>.repopath configs globally\n> in ~/.gitconfig, and cloning kdelibs should automatically do the\n> right thing, ie. use the already available admin repo for the kdelibs\n> clone.\n\nI just realize that this should be already possible now by setting\nsubmodule.<name>.url in ~/.gitconfig. It could automatically\nuse \"git-clone -l -s -n ...\" if the URL is local.\n\nJosef\n"},{"id":"44862","messageId":"7vfy4xhu6p.fsf@assigned-by-dhcp.pobox.com","threadId":"8560","inReplyTo":"466E7A17.CEB0F196@eudaptics.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-12T19:03:10Z","receivedAt":"2007-06-12T19:03:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <J.Sixt@eudaptics.com> writes:\n\n> Lars Hjemli wrote:\n>> Multiple checkout paths for a single submodule will bring havoc on\n>> this plan, so I need to ask: what is the use-case for multiple\n>> checkout paths?\n>\n> A use-case is the admin directory in the KDE repository. It has:\n>\n> KDE (superproject)\n>  +- kdelibs (subproject)\n>  |   +- admin (subproject)\n>  |   +- subdir1\n>  |   +- ...\n>  +- kdebase (subproject)\n>  |   +- admin (subproject)\n>  |   +- subdir2\n>  |   +- ...\n>  +- kdenetwork (subproject)\n>  |   +- admin (subproject)\n>  |   +- subdir3\n>  |   +- ...\n>  ...\n\nIf these three instances of 'admin' are truly the same project\ncreated in multiple places in the directory hierarchy, what is\nthe reason that it is not arranged like this instead?\n\n    KDE\n     +- admin\n     +- kdelibs\n     |   +- subdir1\n     |   +- ...\n     +- kdebase\n     |   +- subdir2\n     |   +- ...\n     +- kdenetwork\n     |   +- subdir3\n     |   +- ...\n     ...\n\nWhen kdelibs/subdir1 needs to access stuff in admin, instead of\ngoing to ../admin, it could very well go to ../../admin couldn't\nit?\n\nIt makes me wonder if the KDE's layout you quoted is a good\npractice we would want to recommend for other people to follow.\nIf not, I doubt it is a good idea to model our important concept\nafter that layout to begin with.\n"},{"id":"44863","messageId":"20070612191048.GX955MdfPADPa@greensroom.kotnet.org","threadId":"8560","inReplyTo":"7vfy4xhu6p.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-06-12T19:10:48Z","receivedAt":"2007-06-12T19:10:48Z","isPatch":true,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Tue, Jun 12, 2007 at 12:03:10PM -0700, Junio C Hamano wrote:\n> Johannes Sixt <J.Sixt@eudaptics.com> writes:\n> \n> > Lars Hjemli wrote:\n> >> Multiple checkout paths for a single submodule will bring havoc on\n> >> this plan, so I need to ask: what is the use-case for multiple\n> >> checkout paths?\n> >\n> > A use-case is the admin directory in the KDE repository. It has:\n> >\n> > KDE (superproject)\n> >  +- kdelibs (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir1\n> >  |   +- ...\n> >  +- kdebase (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir2\n> >  |   +- ...\n> >  +- kdenetwork (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir3\n> >  |   +- ...\n> >  ...\n> \n> If these three instances of 'admin' are truly the same project\n> created in multiple places in the directory hierarchy, what is\n> the reason that it is not arranged like this instead?\n> \n>     KDE\n>      +- admin\n>      +- kdelibs\n>      |   +- subdir1\n>      |   +- ...\n>      +- kdebase\n>      |   +- subdir2\n>      |   +- ...\n>      +- kdenetwork\n>      |   +- subdir3\n>      |   +- ...\n>      ...\n> \n> When kdelibs/subdir1 needs to access stuff in admin, instead of\n> going to ../admin, it could very well go to ../../admin couldn't\n> it?\n\nIn Hannes' example, kdelibs and kdebase are subprojects of their own.\nSurely, you wouldn't want them to depend on something outside of\nthe (sub)project.\n\nBut even in a similar situation where the different parts do not\nexist as separate projects, they may advance at a different pace\nand therefore need different revisions of the same subproject.\n\nskimo\n"},{"id":"44873","messageId":"200706122333.14167.Josef.Weidendorfer@gmx.de","threadId":"8560","inReplyTo":"7vfy4xhu6p.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH 5/5] Add gitmodules(5)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-06-12T21:33:13Z","receivedAt":"2007-06-12T21:33:13Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 12 June 2007, Junio C Hamano wrote:\n> Johannes Sixt <J.Sixt@eudaptics.com> writes:\n\n> > KDE (superproject)\n> >  +- kdelibs (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir1\n> >  |   +- ...\n> >  +- kdebase (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir2\n> >  |   +- ...\n> >  +- kdenetwork (subproject)\n> >  |   +- admin (subproject)\n> >  |   +- subdir3\n> >  |   +- ...\n> >  ...\n> \n> If these three instances of 'admin' are truly the same project\n> created in multiple places in the directory hierarchy, what is\n> the reason that it is not arranged like this instead?\n> \n>     KDE\n>      +- admin\n>      +- kdelibs\n>      |   +- subdir1\n>      |   +- ...\n>      +- kdebase\n>      |   +- subdir2\n>      |   +- ...\n>      +- kdenetwork\n>      |   +- subdir3\n>      |   +- ...\n>      ...\n\nActually, on the SVN server you have this structure.\n\nKDE applications are put together in groups with\nother applications of same kind, e.g. kdenetwork contains\napplications for net access.\n\nNow if you want to work on one KDE application e.g. in\nkdenetwork, you usually checkout _only_ the kdenetwork\ndirectory. There is no need to have other parts; e.g.\nyou usually should be able to use the KDE libs from\nyour distribution - no need to checkout kdelibs.\n\nHowever, the \"admin\" directory above contains the build\nenvironment, which has to be checked out so that kdenetwork\nis able to build. The applications expect the build tools\nto reside in the admin subdirectory.\n\nTo checkout admin inside KDE modules such as kdenetwork,\nSVN externals are used, which is a primitive form of git\nsubmodules, to automatically checkout the admin directory\non checkout of the KDE module.\n\nSo the same admin directory only will be duplicated\nmultiple times only on the developers side where multiple\nKDE modules are checked out.\n\n> When kdelibs/subdir1 needs to access stuff in admin, instead of\n> going to ../admin, it could very well go to ../../admin couldn't\n> it?\n\nUsually, ../../admin will not exist as explicit checkout on\na developers machine. It would be possible to require this, but\nit is much nicer to have each checkout of a KDE module\nself-contained, including a copy of admin.\n\n> It makes me wonder if the KDE's layout you quoted is a good\n> practice we would want to recommend for other people to follow.\n> If not, I doubt it is a good idea to model our important concept\n> after that layout to begin with.\n\nIn the case of KDE, as far as I remember there is no need to\nput _everything_ inside of a the mega supermodule. Every KDE\nmodule (like kdelibs, kdebase, kdenetwork) has its own configure\nrun and checks dependencies.\n\nWhat IMHO is an important use case for submodules is to have the\nsame submodule in multiple different superprojects, as the admin\nexample shows.\n\nJosef\n\nPS: Above admin example is from KDE3. KDE4 uses an\ninstalled build environment (not really sure).\n"}]}