{"thread":{"id":"12499","subject":"[PATCH/RFC v2] git-submodule: multi-level module definition","startedAt":"2008-03-04T16:04:21Z","lastAt":"2008-03-07T01:43:39Z","messageCount":15,"participants":["Ping Yin","Johannes Schindelin","Imran M Yousuf","Junio C Hamano"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"70964","messageId":"1204646661-7776-1-git-send-email-pkufranky@gmail.com","threadId":"12499","inReplyTo":null,"subject":"[PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-03-04T16:04:21Z","receivedAt":"2008-03-04T16:04:21Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"This patch allows multi-level module definition in .gitmodules as\nLinus and Sven Verdoolaege etc. have suggested in mails\n\"Let .git/config specify the url for submodules\"\n(http://article.gmane.org/gmane.comp.version-control.git/48939).\n\nFollowing shows an example of such a .gitmodules.\n\n.gitmodules with with multiple level of indirection\n------------------------------------------------------\n[submodule \"service\"]\n   submodule = crawler\n   submodule = search\n[submodule \"crawler\"]\n   submodule = util\n   submodule = imcrawter\n[submodule \"search\"]\n   submodule = util\n   submodule = imsearch\n[submodule \"util\"]\n   url = git://xyzzy/util.git\n[submodule \"imsearch\"]\n   path = search/imsearch\n   url = git://xyzzy/imsearch.git\n[submodule \"imcrawler\"]\n   path = crawler/imcrawter\n   url = git://xyzzy/imcrawter.git\n------------------------------------------------------\n\nTo simplify the case, submodule sections with submodule attribute should\nhave neither path attribute nor url attribute (if have, should be ignored).\n\nAn option '-m|--module-name' is introduced to designate submodules\nby logical module names instead of module paths. So follwoing\ncommands pairs (1,2), (3,4) will be equivalent.\n\n--------------------------------------\n$ git submodule a b c           (1)\n$ git submodule -m all          (2)\n$ git submodule init a b        (3)\n$ git submodule -m init all1    (4)\n--------------------------------------\n\n\"-m|--module-name\" options is introduced with which modules are designated\n by logical names instead of real paths as following example shows.\n\nIdentical commands forms with/without \"--module-name\"\n---------------------------------------------------\n$ git submodule XXX util imcrawler              (1)\n$ git submodule XXX -n crawler                  (2)\n$ git submodule XXX util imcrawler imsearch     (3)\n$ git submodule XXX -n service                  (4)\n$ git submodule XXX -n crawler search           (5)\n\n* XXX represents status, update or init, but not add\n* (1) and (2) are idetical conditionally (explained below)\n* (3), (4) and (5) are identical conditionally\n---------------------------------------------------\n\nThere are still minor difference between these two forms.\n\nIn the no \"--module-name\" form, the path parameter may be not the real submodule\npath, and it just acts as the filter for real submodule paths. While In the\n \"--module-name\" form, name parameter must be the logical name, and the real\npaths corresponding to the logical name may be neither a submodule path nor\neven existent.\n\nHow to handle such a path depends on the subcommand.\n - status: Output 0{40} as the sha1. Doing this can remind the user to\n   add the path as submodule or delete the path from .gitmodules.\n - update: Skip that path and issue a \"Not a submodule\" warning\n - init: Also init for that path\n\nSo in the example above, commands (1) and (2) are identical only when util and\nimcrawler are already submodules.\n\nWith \"--module-name\" option, now we can add submodules in batch.\n\nThe former workflow to add submodules is adding one by one with\n\"git submodule add url path\" which then modifies .gitmodules. However,\nsometimes it may be more convenient to work in the reverse way: edit\n.gitmodules first and then add submodules in batch.\n\nNow \"git submodule add --module-name modulename\" can help us to do that.\nIt will find all submodules corresponding to the logical name and add them\nin batch by using the path and url from .gitmodules. Of course, it will skip\nthose paths which have already been submodules.\n\nSigned-off-by: Ping Yin <pkufranky@gmail.com>\n---\n git-submodule.sh |  131 +++++++++++++++++++++++++++++++++++++++++++++++-------\n 1 files changed, 114 insertions(+), 17 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex a6aaf40..13517b2 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -13,6 +13,7 @@ command=\n branch=\n quiet=\n cached=\n+use_module_name=\n \n #\n # print stuff on stdout unless -q was specified\n@@ -81,6 +82,75 @@ module_name()\n }\n \n #\n+# List all submodule info line by line by given names (path\\tname\\turl)\n+# $@ = module names\n+#\n+module_info_by_name() {\n+\t(\n+\texport GIT_CONFIG=.gitmodules\n+\t# When names is not given, list all module info\n+\tif test $# = 0\n+\tthen\n+\t\tnames=$(git config --get-regexp 'submodule.*.url' |\n+\t\t\tsed 's/submodule.\\(.*\\).url .*$/\\1/' 2>/dev/null\n+\t\t\t)\n+\t\tfor name in $names\n+\t\tdo\n+\t\t\tif git config submodule.$name.submodule >/dev/null 2>&1\n+\t\t\tthen\n+\t\t\t\tcontinue\n+\t\t\tfi\n+\t\t\turl=$(git config submodule.$name.url)\n+\t\t\tpath=$(git config submodule.$name.path) || path=\"$name\"\n+\t\t\tsha1=$(git ls-files --stage $path | grep -e '^160000' |\n+\t\t\t\tawk '{print $2}')\n+\t\t\ttest -z \"$sha1\" && sha1=0000000000000000000000000000000000000000\n+\t\t\techo \"$sha1\t$path\t$name\t$url\"\n+\t\tdone\n+\t\texit\n+\tfi\n+\n+\tfor name\n+\tdo\n+\t\tlocal names=$(git config --get-all submodule.$name.submodule)\n+\t\tif test -n \"$names\"\n+\t\tthen\n+\t\t\tmodule_info_by_name $names\n+\t\telse\n+\t\t\turl=$(git config submodule.$name.url)\n+\t\t\ttest -z \"$url\" && continue\n+\t\t\tpath=$(git config submodule.$name.path) || path=\"$name\"\n+\t\t\tsha1=$(git ls-files --stage $path | grep -e '^160000' |\n+\t\t\t\tawk '{print $2}')\n+\t\t\ttest -z \"$sha1\" && sha1=0000000000000000000000000000000000000000\n+\t\t\techo \"$sha1\t$path\t$name\t$url\"\n+\t\tfi\n+\tdone\n+\t) | LC_ALL=C sort -u\n+}\n+\n+module_info() {\n+\tif test -n \"$use_module_name\"\n+\tthen\n+\t\tmodule_info_by_name \"$@\"\n+\telse\n+\t\tgit ls-files --stage -- \"$@\" | grep -e '^160000 ' |\n+\t\twhile read mode sha1 stage path\n+\t\tdo\n+\t\t\tname=$(module_name \"$path\")\n+\t\t\tif test -n \"$name\"\n+\t\t\tthen\n+\t\t\t\turl=$(git config submodule.\"$name\".url)\n+\t\t\t\techo \"$sha1\t$path\t$name\t$url\"\n+\t\t\telse\n+\t\t\t\techo \"$sha1\t$path\t\t\"\n+\t\t\tfi\n+\t\tdone | LC_ALL=C sort -u\n+\tfi\n+\n+}\n+\n+#\n # Clone a submodule\n #\n # Prior to calling, cmd_update checks that a possibly existing\n@@ -146,6 +216,17 @@ cmd_add()\n \t\tshift\n \tdone\n \n+\tif test -n \"$use_module_name\"\n+\tthen\n+\t\tmodule_info \"$@\" |\n+\t\twhile read sha1 path name url\n+\t\tdo\n+\t\t\tuse_module_name=\n+\t\t\tcmd_add \"$url\" \"$path\"\n+\t\tdone\n+\t\treturn\n+\tfi\n+\n \trepo=$1\n \tpath=$2\n \n@@ -220,15 +301,16 @@ cmd_init()\n \t\tshift\n \tdone\n \n-\tgit ls-files --stage -- \"$@\" | grep -e '^160000 ' |\n-\twhile read mode sha1 stage path\n+\tmodule_info \"$@\" |\n+\twhile read sha1 path name url\n \tdo\n+\t\ttest -z \"$name\" &&\n+\t\tsay \"No submodule mapping found in .gitmodules for path '$path'\" &&\n+\t\tcontinue\n \t\t# Skip already registered paths\n-\t\tname=$(module_name \"$path\") || exit\n-\t\turl=$(git config submodule.\"$name\".url)\n-\t\ttest -z \"$url\" || continue\n+\t\tgit config submodule.\"$name\".url >/dev/null 2>&1 &&\n+\t\tcontinue\n \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 '$path' in .gitmodules\"\n \n@@ -274,12 +356,18 @@ cmd_update()\n \t\tshift\n \tdone\n \n-\tgit ls-files --stage -- \"$@\" | grep -e '^160000 ' |\n-\twhile read mode sha1 stage path\n+\tmodule_info \"$@\" |\n+\twhile read sha1 path name url\n \tdo\n-\t\tname=$(module_name \"$path\") || exit\n-\t\turl=$(git config submodule.\"$name\".url)\n-\t\tif test -z \"$url\"\n+\t\tif test $sha1 = 0000000000000000000000000000000000000000\n+\t\tthen\n+\t\t\tsay \"Not a submodule: $name @ $path\"\n+\t\t\tcontinue\n+\t\telif test -z \"$name\"\n+\t\tthen\n+\t\t\tsay \"No submodule mapping found in .gitmodules for path '$path'\"\n+\t\t\tcontinue\n+\t\telif 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@@ -357,15 +445,21 @@ cmd_status()\n \t\tshift\n \tdone\n \n-\tgit ls-files --stage -- \"$@\" | grep -e '^160000 ' |\n-\twhile read mode sha1 stage path\n+\tmodule_info \"$@\" |\n+\twhile read sha1 path name url\n \tdo\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\tif test $sha1 = 0000000000000000000000000000000000000000\n+\t\tthen\n+\t\t\tsay \"*$sha1 $path\"\n+\t\t\tcontinue\n+\t\telif test -z \"$name\"\n+\t\tthen\n+\t\t\tsay \"No submodule mapping found in .gitmodules for path '$path'\"\n+\t\t\tcontinue\n+\t\telif test -z \"$url\" || ! test -d \"$path\"/.git\n \t\tthen\n \t\t\tsay \"-$sha1 $path\"\n-\t\t\tcontinue;\n+\t\t\tcontinue\n \t\tfi\n \t\tset_name_rev \"$path\" \"$sha1\"\n \t\tif git diff-files --quiet -- \"$path\"\n@@ -408,6 +502,9 @@ do\n \t--cached)\n \t\tcached=1\n \t\t;;\n+\t-m|--module-name)\n+\t\tuse_module_name=1\n+\t\t;;\n \t--)\n \t\tbreak\n \t\t;;\n-- \n1.5.4.3.347.g5314c\n\n"},{"id":"70969","messageId":"alpine.LSU.1.00.0803041608420.22527@racer.site","threadId":"12499","inReplyTo":"1204646661-7776-1-git-send-email-pkufranky@gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-04T16:12:22Z","receivedAt":"2008-03-04T16:12:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 5 Mar 2008, Ping Yin wrote:\n\n> [submodule \"service\"]\n>    submodule = crawler\n>    submodule = search\n> [submodule \"crawler\"]\n>    submodule = util\n>    submodule = imcrawter\n> [submodule \"search\"]\n>    submodule = util\n>    submodule = imsearch\n> [submodule \"util\"]\n>    url = git://xyzzy/util.git\n> [submodule \"imsearch\"]\n>    path = search/imsearch\n>    url = git://xyzzy/imsearch.git\n> [submodule \"imcrawler\"]\n>    path = crawler/imcrawter\n>    url = git://xyzzy/imcrawter.git\n\nIn \"git remote\", we also have a notion of groups.  It looks much nicer, \nIMO.  So why not do this?\n\n[submodules]\n\tservice = crawler search\n\tcrawler = util imcrawler\n\tsearch = util imsearch\n[submodule \"util\"]\n    url = git://xyzzy/util.git\n[submodule \"imsearch\"]\n   path = search/imsearch\n   url = git://xyzzy/imsearch.git\n[submodule \"imcrawler\"]\n   path = crawler/imcrawter\n   url = git://xyzzy/imcrawter.git\n\nHowever, I think that being able to specify submodule groups recursively \nis only adding to confusion, so I would even prefer this:\n\n[submodules]\n\tservice = util imcrawler imsearch\n\tcrawler = util imcrawler\n\tsearch = util imsearch\n[...]\n\nCiao,\nDscho\n"},{"id":"71021","messageId":"46dff0320803041813y2d2acfddjb7f973a54e5d64c9@mail.gmail.com","threadId":"12499","inReplyTo":"alpine.LSU.1.00.0803041608420.22527@racer.site","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-03-05T02:13:17Z","receivedAt":"2008-03-05T02:13:17Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Wed, Mar 5, 2008 at 12:12 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n>  In \"git remote\", we also have a notion of groups.  It looks much nicer,\n>  IMO.  So why not do this?\n>\n>  [submodules]\n>         service = crawler search\n>         crawler = util imcrawler\n>         search = util imsearch\n>\nHmm, it seems more brief.\n>\n>  However, I think that being able to specify submodule groups recursively\n>  is only adding to confusion, so I would even prefer this:\n>\n>  [submodules]\n>         service = util imcrawler imsearch\n>         crawler = util imcrawler\n>         search = util imsearch\n>  [...]\n>\nThis is fine when number of modules is not much, or user may feel\ninconvenient since they have to type so many module names.\nA hierarchy of modules can help much when having a group of common\nmodules which should be included in most of role-related logical\nmoduels.\n>  Ciao,\n>  Dscho\n>\n\n\n\n-- \nPing Yin\n"},{"id":"71036","messageId":"46dff0320803042316m1921f657wacf63a63491bbda0@mail.gmail.com","threadId":"12499","inReplyTo":"46dff0320803042315t2d89eb6fl325b4b2ef8ddbc44@mail.gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-03-05T07:16:23Z","receivedAt":"2008-03-05T07:16:23Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Wed, Mar 5, 2008 at 11:17 AM, Imran M Yousuf <imyousuf@gmail.com> wrote:\n > On Tue, Mar 4, 2008 at 10:04 PM, Ping Yin <pkufranky@gmail.com> wrote:\n\n>  >  .gitmodules with with multiple level of indirection\n >  >  ------------------------------------------------------\n >  >  [submodule \"service\"]\n >  >    submodule = crawler\n >  >    submodule = search\n >  >  [submodule \"crawler\"]\n >  >    submodule = util\n >  >    submodule = imcrawter\n >  >  [submodule \"search\"]\n >  >    submodule = util\n >  >    submodule = imsearch\n\n >\n\n>  At this point I have few questions - Will Service have its own tree\n >  besides its submodules?\n Now, service itself is not a submodule, and service is just a logical\n name for a group of moduels.\n\n\n >\n >  For your above example of .gitmodules hierarchy if I issue \"git\n >  submodule init -m util\", can you please explain what will be the\n >  outcome, i.e. which modules will be initialized.\n >\n Only the util module will be initialized using the path and url in\n submodule.util.{path,url}\n\n >\n >  --\n\n>  Imran M Yousuf\n >  Entrepreneur & Software Engineer\n >  Smart IT Engineering\n >  Dhaka, Bangladesh\n >  Email: imran@smartitengineering.com\n >  Mobile: +880-1711402557\n >\n\n\n-- \nPing Yin\n"},{"id":"71041","messageId":"7bfdc29a0803042340k2ea6fc1cq435205f1da71bbb0@mail.gmail.com","threadId":"12499","inReplyTo":"46dff0320803042316m1921f657wacf63a63491bbda0@mail.gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Imran M Yousuf","fromEmail":"imyousuf@gmail.com","sentAt":"2008-03-05T07:40:41Z","receivedAt":"2008-03-05T07:40:41Z","isPatch":true,"sender":{"key":"imyousuf@gmail.com","avatar":"https://gravatar.com/avatar/fda3c870262849d03c7b9c4d288842e128d6d80769fa7bc2d22731b7597928be?d=mp&s=160"},"body":"On Wed, Mar 5, 2008 at 1:16 PM, Ping Yin <pkufranky@gmail.com> wrote:\n>\n> On Wed, Mar 5, 2008 at 11:17 AM, Imran M Yousuf <imyousuf@gmail.com> wrote:\n>   > On Tue, Mar 4, 2008 at 10:04 PM, Ping Yin <pkufranky@gmail.com> wrote:\n>\n>  >  >  .gitmodules with with multiple level of indirection\n>   >  >  ------------------------------------------------------\n>   >  >  [submodule \"service\"]\n>   >  >    submodule = crawler\n>   >  >    submodule = search\n>   >  >  [submodule \"crawler\"]\n>   >  >    submodule = util\n>   >  >    submodule = imcrawter\n>   >  >  [submodule \"search\"]\n>   >  >    submodule = util\n>   >  >    submodule = imsearch\n>\n>   >\n>\n>  >  At this point I have few questions - Will Service have its own tree\n>   >  besides its submodules?\n>   Now, service itself is not a submodule, and service is just a logical\n>   name for a group of moduels.\n>\nIf I am not mistaken I can do it now as well, by \"git submodule add\nrepo path\". What would be the difference with this and your approach?\n>\n>   >\n>   >  For your above example of .gitmodules hierarchy if I issue \"git\n>   >  submodule init -m util\", can you please explain what will be the\n>   >  outcome, i.e. which modules will be initialized.\n>   >\n>   Only the util module will be initialized using the path and url in\n>   submodule.util.{path,url}\n>\nI got that part as thats how git-submodules currently work; Actually\nwhat I wanted to know is as util is referenced to several logical\nsubmodules, will they be initialized as well? that means wherever util\nis referenced it will be initialized; is that what it means?\n>   >\n>   >  --\n>\n>   >\n>\n>\n>  --\n>  Ping Yin\n>\n>\n> --\n>  To unsubscribe from this list: send the line \"unsubscribe git\" in\n>  the body of a message to majordomo@vger.kernel.org\n>  More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\n\n\n-- \nImran M Yousuf\nEntrepreneur & Software Engineer\nSmart IT Engineering\nDhaka, Bangladesh\nEmail: imran@smartitengineering.com\nMobile: +880-1711402557\n"},{"id":"71042","messageId":"46dff0320803042353u7e2e1789x514a2f81b7204277@mail.gmail.com","threadId":"12499","inReplyTo":"7bfdc29a0803042340k2ea6fc1cq435205f1da71bbb0@mail.gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-03-05T07:53:07Z","receivedAt":"2008-03-05T07:53:07Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Wed, Mar 5, 2008 at 3:40 PM, Imran M Yousuf <imyousuf@gmail.com> wrote:\n> On Wed, Mar 5, 2008 at 1:16 PM, Ping Yin <pkufranky@gmail.com> wrote:\n>  >\n>  > On Wed, Mar 5, 2008 at 11:17 AM, Imran M Yousuf <imyousuf@gmail.com> wrote:\n>  >   > On Tue, Mar 4, 2008 at 10:04 PM, Ping Yin <pkufranky@gmail.com> wrote:\n>  >\n>  >  >  >  .gitmodules with with multiple level of indirection\n>  >   >  >  ------------------------------------------------------\n>  >   >  >  [submodule \"service\"]\n>  >   >  >    submodule = crawler\n>  >   >  >    submodule = search\n>  >   >  >  [submodule \"crawler\"]\n>  >   >  >    submodule = util\n>  >   >  >    submodule = imcrawter\n>  >   >  >  [submodule \"search\"]\n>  >   >  >    submodule = util\n>  >   >  >    submodule = imsearch\n>  >\n>  >   >\n>  >\n>  >  >  At this point I have few questions - Will Service have its own tree\n>  >   >  besides its submodules?\n>  >   Now, service itself is not a submodule, and service is just a logical\n>  >   name for a group of moduels.\n>  >\n>  If I am not mistaken I can do it now as well, by \"git submodule add\n>  repo path\". What would be the difference with this and your approach?\nNo difference at this point. But using logical name can help add\nmodules in batch such as \"git submodule add -m service\"\n>\n> >\n>  >   >\n>  >   >  For your above example of .gitmodules hierarchy if I issue \"git\n>  >   >  submodule init -m util\", can you please explain what will be the\n>  >   >  outcome, i.e. which modules will be initialized.\n>  >   >\n>  >   Only the util module will be initialized using the path and url in\n>  >   submodule.util.{path,url}\n>  >\n>  I got that part as thats how git-submodules currently work; Actually\n>  what I wanted to know is as util is referenced to several logical\n>  submodules, will they be initialized as well? that means wherever util\n>  is referenced it will be initialized; is that what it means?\n>  >   >\nSince the user designate only util module, we needn't automatically\ndeduce the related modules for them. And as you have said, we can't\ndeduce well since util may be referenced by several logical modules.\n>  >   >  --\n>  >\n>  >   >\n>  >\n>  >\n>  >  --\n>  >  Ping Yin\n>\n> >\n>  >\n>  > --\n>  >  To unsubscribe from this list: send the line \"unsubscribe git\" in\n>  >  the body of a message to majordomo@vger.kernel.org\n>  >  More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>  >\n>\n>\n>\n>  --\n>\n>\n> Imran M Yousuf\n>  Entrepreneur & Software Engineer\n>  Smart IT Engineering\n>  Dhaka, Bangladesh\n>  Email: imran@smartitengineering.com\n>  Mobile: +880-1711402557\n>\n\n\n\n-- \nPing Yin\n"},{"id":"71044","messageId":"7bfdc29a0803050003j625b21a0m1f9af3f5554ef22@mail.gmail.com","threadId":"12499","inReplyTo":"46dff0320803042353u7e2e1789x514a2f81b7204277@mail.gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Imran M Yousuf","fromEmail":"imyousuf@gmail.com","sentAt":"2008-03-05T08:03:13Z","receivedAt":"2008-03-05T08:03:13Z","isPatch":true,"sender":{"key":"imyousuf@gmail.com","avatar":"https://gravatar.com/avatar/fda3c870262849d03c7b9c4d288842e128d6d80769fa7bc2d22731b7597928be?d=mp&s=160"},"body":"On Wed, Mar 5, 2008 at 1:53 PM, Ping Yin <pkufranky@gmail.com> wrote:\n> On Wed, Mar 5, 2008 at 3:40 PM, Imran M Yousuf <imyousuf@gmail.com> wrote:\n>  > On Wed, Mar 5, 2008 at 1:16 PM, Ping Yin <pkufranky@gmail.com> wrote:\n>  >  >\n>  >  > On Wed, Mar 5, 2008 at 11:17 AM, Imran M Yousuf <imyousuf@gmail.com> wrote:\n>  >  >   > On Tue, Mar 4, 2008 at 10:04 PM, Ping Yin <pkufranky@gmail.com> wrote:\n>  >  >\n>  >  >  >  >  .gitmodules with with multiple level of indirection\n>  >  >   >  >  ------------------------------------------------------\n>  >  >   >  >  [submodule \"service\"]\n>  >  >   >  >    submodule = crawler\n>  >  >   >  >    submodule = search\n>  >  >   >  >  [submodule \"crawler\"]\n>  >  >   >  >    submodule = util\n>  >  >   >  >    submodule = imcrawter\n>  >  >   >  >  [submodule \"search\"]\n>  >  >   >  >    submodule = util\n>  >  >   >  >    submodule = imsearch\n>  >  >\n>  >  >   >\n>  >  >\n>  >  >  >  At this point I have few questions - Will Service have its own tree\n>  >  >   >  besides its submodules?\n>  >  >   Now, service itself is not a submodule, and service is just a logical\n>  >  >   name for a group of moduels.\n>  >  >\n>  >  If I am not mistaken I can do it now as well, by \"git submodule add\n>  >  repo path\". What would be the difference with this and your approach?\n>  No difference at this point. But using logical name can help add\n>  modules in batch such as \"git submodule add -m service\"\n>\n\nOk I am working on something similar a recurse command for git\nsubmodule; thats why I asked it. Hopefully will appear in mailing list\ntomorrow :).\n\n> >\n>  > >\n>  >  >   >\n>  >  >   >  For your above example of .gitmodules hierarchy if I issue \"git\n>  >  >   >  submodule init -m util\", can you please explain what will be the\n>  >  >   >  outcome, i.e. which modules will be initialized.\n>  >  >   >\n>  >  >   Only the util module will be initialized using the path and url in\n>  >  >   submodule.util.{path,url}\n>  >  >\n>  >  I got that part as thats how git-submodules currently work; Actually\n>  >  what I wanted to know is as util is referenced to several logical\n>  >  submodules, will they be initialized as well? that means wherever util\n>  >  is referenced it will be initialized; is that what it means?\n>  >  >   >\n>  Since the user designate only util module, we needn't automatically\n>  deduce the related modules for them. And as you have said, we can't\n>  deduce well since util may be referenced by several logical modules.\n>\n> >  >   >  --\n>  >  >\n>  >  >   >\n>  >  >\n>  >  >\n>  >  >  --\n>  >  >  Ping Yin\n>  >\n>  > >\n>  >  >\n>  >  > --\n>  >  >  To unsubscribe from this list: send the line \"unsubscribe git\" in\n>  >  >  the body of a message to majordomo@vger.kernel.org\n>  >  >  More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>  >  >\n>  >\n>  >\n>  >\n>  >  --\n>  >\n>  >\n>  > Imran M Yousuf\n>  >  Entrepreneur & Software Engineer\n>  >  Smart IT Engineering\n>  >  Dhaka, Bangladesh\n>  >  Email: imran@smartitengineering.com\n>  >  Mobile: +880-1711402557\n>  >\n>\n>\n>\n>  --\n>  Ping Yin\n>\n\n\n\n-- \nImran M Yousuf\nEntrepreneur & Software Engineer\nSmart IT Engineering\nDhaka, Bangladesh\nEmail: imran@smartitengineering.com\nMobile: +880-1711402557\n"},{"id":"71144","messageId":"7vd4q8kbey.fsf@gitster.siamese.dyndns.org","threadId":"12499","inReplyTo":"1204646661-7776-1-git-send-email-pkufranky@gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-05T23:18:13Z","receivedAt":"2008-03-05T23:18:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ping Yin <pkufranky@gmail.com> writes:\n\n> This patch allows multi-level module definition in .gitmodules as\n> Linus and Sven Verdoolaege etc. have suggested in mails\n> \"Let .git/config specify the url for submodules\"\n> (http://article.gmane.org/gmane.comp.version-control.git/48939).\n> \n> Following shows an example of such a .gitmodules.\n>\n> .gitmodules with with multiple level of indirection\n> ------------------------------------------------------\n> [submodule \"service\"]\n>    submodule = crawler\n>    submodule = search\n> ...\n> [submodule \"util\"]\n>    url = git://xyzzy/util.git\n> [submodule \"imsearch\"]\n>    path = search/imsearch\n>    url = git://xyzzy/imsearch.git\n> [submodule \"imcrawler\"]\n>    path = crawler/imcrawter\n>    url = git://xyzzy/imcrawter.git\n> ------------------------------------------------------\n\nI would agree that allowing the user to use a short-hand to name a group\nof modules the user is interested in would be a good idea, but I think\n.gitmodules is a wrong place to do so.  The grouping is a user preference,\nisn't it?\n\nThe place the owner of the repository (not the project) expresses which\nmodules are of interest, what transports she wants to use to access it,\netc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to\nbe used when the user populates that information.\n"},{"id":"71162","messageId":"46dff0320803051754o4b45222es524a62a7cac50b94@mail.gmail.com","threadId":"12499","inReplyTo":"7vd4q8kbey.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-03-06T01:54:58Z","receivedAt":"2008-03-06T01:54:58Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Thu, Mar 6, 2008 at 7:18 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ping Yin <pkufranky@gmail.com> writes:\n>\n>  > This patch allows multi-level module definition in .gitmodules as\n>  > Linus and Sven Verdoolaege etc. have suggested in mails\n>  > \"Let .git/config specify the url for submodules\"\n>  > (http://article.gmane.org/gmane.comp.version-control.git/48939).\n>  >\n>  > Following shows an example of such a .gitmodules.\n>  >\n>  > .gitmodules with with multiple level of indirection\n>  > ------------------------------------------------------\n>  > [submodule \"service\"]\n>  >    submodule = crawler\n>  >    submodule = search\n>  > ...\n>\n> > [submodule \"util\"]\n>  >    url = git://xyzzy/util.git\n>  > [submodule \"imsearch\"]\n>  >    path = search/imsearch\n>  >    url = git://xyzzy/imsearch.git\n>  > [submodule \"imcrawler\"]\n>  >    path = crawler/imcrawter\n>  >    url = git://xyzzy/imcrawter.git\n>  > ------------------------------------------------------\n>\n>  I would agree that allowing the user to use a short-hand to name a group\n>  of modules the user is interested in would be a good idea, but I think\n>  .gitmodules is a wrong place to do so.  The grouping is a user preference,\n>  isn't it?\n>\n>  The place the owner of the repository (not the project) expresses which\n>  modules are of interest, what transports she wants to use to access it,\n>  etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to\n>  be used when the user populates that information.\n>\nNot always the case. In my company environment, we have many\nsubmodules and have a unified hierachy of modules, and we use the same\ntransports ssh. So after top maintainer give the basic module hierachy\nconfig in .gitmodules, other people needn't and even shouldn't\nconsider changing these common config. If other people have special\nneeds, they can of course edit .git/config to add new hierachy or\noverride existing ones in .gitmodules. However, it's better to put the\ncommon config in .gitmodules to pass to every one.\n\nI think this may not be a special requirement for my company, so\nletting .gitmodule record the common module hierachy should be a\ncommon requirement in a company environment.\n\n\n-- \nPing Yin\n"},{"id":"71165","messageId":"7bfdc29a0803051816r752d3027yff83a78e1769216a@mail.gmail.com","threadId":"12499","inReplyTo":"46dff0320803051754o4b45222es524a62a7cac50b94@mail.gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Imran M Yousuf","fromEmail":"imyousuf@gmail.com","sentAt":"2008-03-06T02:16:28Z","receivedAt":"2008-03-06T02:16:28Z","isPatch":true,"sender":{"key":"imyousuf@gmail.com","avatar":"https://gravatar.com/avatar/fda3c870262849d03c7b9c4d288842e128d6d80769fa7bc2d22731b7597928be?d=mp&s=160"},"body":"On Thu, Mar 6, 2008 at 7:54 AM, Ping Yin <pkufranky@gmail.com> wrote:\n>\n> On Thu, Mar 6, 2008 at 7:18 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>  > Ping Yin <pkufranky@gmail.com> writes:\n>  >\n>  >  > This patch allows multi-level module definition in .gitmodules as\n>  >  > Linus and Sven Verdoolaege etc. have suggested in mails\n>  >  > \"Let .git/config specify the url for submodules\"\n>  >  > (http://article.gmane.org/gmane.comp.version-control.git/48939).\n>  >  >\n>  >  > Following shows an example of such a .gitmodules.\n>  >  >\n>  >  > .gitmodules with with multiple level of indirection\n>  >  > ------------------------------------------------------\n>  >  > [submodule \"service\"]\n>  >  >    submodule = crawler\n>  >  >    submodule = search\n>  >  > ...\n>  >\n>  > > [submodule \"util\"]\n>  >  >    url = git://xyzzy/util.git\n>  >  > [submodule \"imsearch\"]\n>  >  >    path = search/imsearch\n>  >  >    url = git://xyzzy/imsearch.git\n>  >  > [submodule \"imcrawler\"]\n>  >  >    path = crawler/imcrawter\n>  >  >    url = git://xyzzy/imcrawter.git\n>  >  > ------------------------------------------------------\n>  >\n>  >  I would agree that allowing the user to use a short-hand to name a group\n>  >  of modules the user is interested in would be a good idea, but I think\n>  >  .gitmodules is a wrong place to do so.  The grouping is a user preference,\n>  >  isn't it?\n>  >\n>  >  The place the owner of the repository (not the project) expresses which\n>  >  modules are of interest, what transports she wants to use to access it,\n>  >  etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to\n>  >  be used when the user populates that information.\n>  >\n>  Not always the case. In my company environment, we have many\n>  submodules and have a unified hierachy of modules, and we use the same\n>  transports ssh. So after top maintainer give the basic module hierachy\n>  config in .gitmodules, other people needn't and even shouldn't\n>  consider changing these common config. If other people have special\n>  needs, they can of course edit .git/config to add new hierachy or\n>  override existing ones in .gitmodules. However, it's better to put the\n>  common config in .gitmodules to pass to every one.\n>\n\nI am a bit confused about why we need it as from discussion earlier we\nsee that there isn't much difference with the currently available\nmechanism. I still do not see any advantage over the currently\navailable system other than having an alternate way to do a thing\nalready can be done.\n\n>  I think this may not be a special requirement for my company, so\n>  letting .gitmodule record the common module hierachy should be a\n>  common requirement in a company environment.\n>\n\nActually our company has a high modular structure, using maven makes\nit easier to main and link modules. I would find an in place submodule\nmuch more handy for such requirement.\n\n>\n>  --\n>  Ping Yin\n>\n>\n> --\n>  To unsubscribe from this list: send the line \"unsubscribe git\" in\n>  the body of a message to majordomo@vger.kernel.org\n>  More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\n\n\n-- \nImran M Yousuf\nEntrepreneur & Software Engineer\nSmart IT Engineering\nDhaka, Bangladesh\nEmail: imran@smartitengineering.com\nMobile: +880-1711402557\n"},{"id":"71168","messageId":"alpine.LSU.1.00.0803060330210.15786@racer.site","threadId":"12499","inReplyTo":"46dff0320803051754o4b45222es524a62a7cac50b94@mail.gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-06T02:32:34Z","receivedAt":"2008-03-06T02:32:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 6 Mar 2008, Ping Yin wrote:\n\n> On Thu, Mar 6, 2008 at 7:18 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> > Ping Yin <pkufranky@gmail.com> writes:\n> >\n> >  > This patch allows multi-level module definition in .gitmodules as\n> >  > Linus and Sven Verdoolaege etc. have suggested in mails\n> >  > \"Let .git/config specify the url for submodules\"\n> >  > (http://article.gmane.org/gmane.comp.version-control.git/48939).\n> >  >\n> >  > Following shows an example of such a .gitmodules.\n> >  >\n> >  > .gitmodules with with multiple level of indirection\n> >  > ------------------------------------------------------\n> >  > [submodule \"service\"]\n> >  >    submodule = crawler\n> >  >    submodule = search\n> >  > ...\n> >\n> > > [submodule \"util\"]\n> >  >    url = git://xyzzy/util.git\n> >  > [submodule \"imsearch\"]\n> >  >    path = search/imsearch\n> >  >    url = git://xyzzy/imsearch.git\n> >  > [submodule \"imcrawler\"]\n> >  >    path = crawler/imcrawter\n> >  >    url = git://xyzzy/imcrawter.git\n> >  > ------------------------------------------------------\n> >\n> >  I would agree that allowing the user to use a short-hand to name a group\n> >  of modules the user is interested in would be a good idea, but I think\n> >  .gitmodules is a wrong place to do so.  The grouping is a user preference,\n> >  isn't it?\n> >\n> >  The place the owner of the repository (not the project) expresses which\n> >  modules are of interest, what transports she wants to use to access it,\n> >  etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to\n> >  be used when the user populates that information.\n> >\n> Not always the case.\n\nIf it is _not_ always the case, .gitmodules is definitely the wrong place, \nand $GIT_DIR/config is.\n\nJust like we need \"init && update\", and not have \"init\" update implicitly, \nlike some people wish (who forget that other people might have other \nwishes), we need to allow for different options here.\n\nAnd as .gitmodules is _meant_ to be tracked, it is not the place to \nexpress individual wishes differing from the colleagues' wishes.\n\nCiao,\nDscho\n\n"},{"id":"71171","messageId":"7vejaoldgu.fsf@gitster.siamese.dyndns.org","threadId":"12499","inReplyTo":"46dff0320803051754o4b45222es524a62a7cac50b94@mail.gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-06T03:48:33Z","receivedAt":"2008-03-06T03:48:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Ping Yin\" <pkufranky@gmail.com> writes:\n\n>>  I would agree that allowing the user to use a short-hand to name a group\n>>  of modules the user is interested in would be a good idea, but I think\n>>  .gitmodules is a wrong place to do so.  The grouping is a user preference,\n>>  isn't it?\n>>\n>>  The place the owner of the repository (not the project) expresses which\n>>  modules are of interest, what transports she wants to use to access it,\n>>  etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to\n>>  be used when the user populates that information.\n>>\n> Not always the case. In my company environment, we have many\n> submodules and have a unified hierachy of modules,...\n> ..., it's better to put the\n> common config in .gitmodules to pass to every one.\n\nI think we are saying the same thing, and I do not understand why you\nsound so upset about my comments.  I never said it is bad to copy the\n\"hints\" supplied by .gitmodules verbatim to $GIT_DIR/config.\n\nSee how the current cmd_init() uses the information in .gitmodules.  It\ncould later become interactive to allow users to override what's in there,\nbut by default it simply uses the information from .gitmodules verbatim.\n\nIn the special case of everybody using exactly the same settings, you can\nhave \"all\" submodule group alias in .gitmodules, and the user can say \"git\nsubmodule init all\", which would set up the set of the modules the user\nwould work with, using the \"hints\" in the .gitmodules distributed company\nwide verbatim.\n\nOne of the goal of the overall design of submodules is _not forcing_ but\nstill allowing such uniformity, and I think using $GIT_DIR/config as\nauthoritative and treating in-tree .gitmodules as hint to prime\n$GIT_DIR/config is quite fundamental to that design.  Let's make sure we\ndo not needlessly deviate from it.\n\nBecause names to name things are fundamental part of the communication, I\ndo not think we would want to allow users to call A what the project as a\nwhole calls B.  The use of .gitmodules by the current module_name() that\nmaps a specific name to a path is not just fine but is preferred for this\nreason (i.e. if we copied them to $GIT_DIR/config it would only introduce\ntower-of-babel confusion).\n\nHowever, a short-hand to name groups of submodules is not just about\nnaming one thing with one name, but has user convenience aspect too.\nThere should be per-user customizability built into the design.  You could\nprobably fix this by making the code first consult $GIT_DIR/config and\nthen fall back on in-tree .gitmodules file.\n\nBy the way, in your patch, I notice that quoting of $name is often very\nloosely done.  I do not think we have officially defined what the allowed\nrepertoire of module name characters are, but we probably should declare\nthe rules and make sure the code actively enforces it to prevent future\ngrief.  I'd say the same restriction as we have for refnames, except\nthat we do not allow slashes either, is good enough?\n"},{"id":"71188","messageId":"46dff0320803052118j2296a2d4p397fa889f8cea45b@mail.gmail.com","threadId":"12499","inReplyTo":"alpine.LSU.1.00.0803060330210.15786@racer.site","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-03-06T05:18:17Z","receivedAt":"2008-03-06T05:18:17Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Thu, Mar 6, 2008 at 10:32 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n>\n>  > >  The place the owner of the repository (not the project) expresses which\n>  > >  modules are of interest, what transports she wants to use to access it,\n>  > >  etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to\n>  > >  be used when the user populates that information.\n>  > >\n>  > Not always the case.\n>\n>  If it is _not_ always the case, .gitmodules is definitely the wrong place,\n>  and $GIT_DIR/config is.\n>\n>  Just like we need \"init && update\", and not have \"init\" update implicitly,\n>  like some people wish (who forget that other people might have other\n>  wishes), we need to allow for different options here.\n>\n>  And as .gitmodules is _meant_ to be tracked, it is not the place to\n>  express individual wishes differing from the colleagues' wishes.\n>\nAs an analogy, .gitignore is for colleagues' wishes and\n.git/info/exluces is for individual wishes.\nThe same, .gitmodules is for colleagues' wishes and .git/config is for\nindividual wishes.\n\nThere are always common cases and special cases, so we need a machinsm\nto support both of them.\n>  Ciao,\n>  Dscho\n>\n>\n\n\n\n-- \nPing Yin\n"},{"id":"71193","messageId":"46dff0320803052148wd4fe5e3hfde72b4362b0cc8b@mail.gmail.com","threadId":"12499","inReplyTo":"7vejaoldgu.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-03-06T05:48:06Z","receivedAt":"2008-03-06T05:48:06Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Thu, Mar 6, 2008 at 11:48 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Ping Yin\" <pkufranky@gmail.com> writes:\n>\n>\n\n>  I think we are saying the same thing, and I do not understand why you\n>  sound so upset about my comments.  I never said it is bad to copy the\n>  \"hints\" supplied by .gitmodules verbatim to $GIT_DIR/config.\n>\n>  See how the current cmd_init() uses the information in .gitmodules.  It\n>  could later become interactive to allow users to override what's in there,\n>  but by default it simply uses the information from .gitmodules verbatim.\n>\n>  However, a short-hand to name groups of submodules is not just about\n>  naming one thing with one name, but has user convenience aspect too.\n>  There should be per-user customizability built into the design.  You could\n>  probably fix this by making the code first consult $GIT_DIR/config and\n>  then fall back on in-tree .gitmodules file.\n\nWe agree on this point and 'fall back' is what i will try to do. Our\ndifference is the\n way to implement it. Since finally we can fall back to .gitmodules\nwhen information\n is not found in .git/config, why always use 'git init' at the first.\n\n'git init' should be useful when a user has many special requirements which can\nhelp the user copy info from .gitmodules to .git/config and then edit\n.git/config.\nBut in many cases (at least in my company), users may not have special\nrequirements,\nso he needn't use 'git init'.\n\nSo now 'git init' is not the first class citizen, it's just a util to\nhelp users when they need it.\n\nAnd there may be inconsistence between .git/config and .gitmodules\nwhen always using 'git init'\nat first. If .gitmodules has changed in the upstream, what should user\ndo? run 'git init' again? That's\nnot so easy.  Since .git/config has a whole copy of .gitmodules, the\nuser has no easy way to know\nwhich entries he has changed which shouldn't follow the upstream changes.\n\n>\n>  By the way, in your patch, I notice that quoting of $name is often very\n>  loosely done.  I do not think we have officially defined what the allowed\n>  repertoire of module name characters are, but we probably should declare\n>  the rules and make sure the code actively enforces it to prevent future\n>  grief.  I'd say the same restriction as we have for refnames, except\n>  that we do not allow slashes either, is good enough?\n>\nI think it's enough.\n\nIn this bash script, there are many places which don't/can't handle\nnames containing whitespace\nwell. So the decaring a naming rule for the modue name sounds good.\n\n\n\n-- \nPing Yin\n"},{"id":"71304","messageId":"46dff0320803061743s75d79aefj931e3f09999b3bf7@mail.gmail.com","threadId":"12499","inReplyTo":"46dff0320803052148wd4fe5e3hfde72b4362b0cc8b@mail.gmail.com","subject":"Re: [PATCH/RFC v2] git-submodule: multi-level module definition","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-03-07T01:43:39Z","receivedAt":"2008-03-07T01:43:39Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Thu, Mar 6, 2008 at 1:48 PM, Ping Yin <pkufranky@gmail.com> wrote:\n> On Thu, Mar 6, 2008 at 11:48 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>  > \"Ping Yin\" <pkufranky@gmail.com> writes:\n>  >\n>  >\n>\n>\n> >  I think we are saying the same thing, and I do not understand why you\n>  >  sound so upset about my comments.  I never said it is bad to copy the\n>  >  \"hints\" supplied by .gitmodules verbatim to $GIT_DIR/config.\n>  >\n>  >  See how the current cmd_init() uses the information in .gitmodules.  It\n>  >  could later become interactive to allow users to override what's in there,\n>  >  but by default it simply uses the information from .gitmodules verbatim.\n>  >\n>\n> >  However, a short-hand to name groups of submodules is not just about\n>  >  naming one thing with one name, but has user convenience aspect too.\n>  >  There should be per-user customizability built into the design.  You could\n>  >  probably fix this by making the code first consult $GIT_DIR/config and\n>  >  then fall back on in-tree .gitmodules file.\n>\n>  We agree on this point and 'fall back' is what i will try to do. Our\n>  difference is the\n>   way to implement it. Since finally we can fall back to .gitmodules\n>  when information\n>   is not found in .git/config, why always use 'git init' at the first.\n>\n>  'git init' should be useful when a user has many special requirements which can\n>  help the user copy info from .gitmodules to .git/config and then edit\n>  .git/config.\n>  But in many cases (at least in my company), users may not have special\n>  requirements,\n>  so he needn't use 'git init'.\n>\n>  So now 'git init' is not the first class citizen, it's just a util to\n>  help users when they need it.\n>\n>  And there may be inconsistence between .git/config and .gitmodules\n>  when always using 'git init'\n>  at first. If .gitmodules has changed in the upstream, what should user\n>  do? run 'git init' again? That's\n>  not so easy.  Since .git/config has a whole copy of .gitmodules, the\n>  user has no easy way to know\n>  which entries he has changed which shouldn't follow the upstream changes.\n>\n>\n>  >\n>  >  By the way, in your patch, I notice that quoting of $name is often very\n>  >  loosely done.  I do not think we have officially defined what the allowed\n>  >  repertoire of module name characters are, but we probably should declare\n>  >  the rules and make sure the code actively enforces it to prevent future\n>  >  grief.  I'd say the same restriction as we have for refnames, except\n>  >  that we do not allow slashes either, is good enough?\n>  >\n>  I think it's enough.\nIt may be not enough. There are many places using code like 'while\nread name path',\nand path and name are the same by default, so name and path should use the\nsame name restriction. But path will have slashes and multibyte\ncharacters. So how\nabout just limiting name and path not containing whitespace characters?\n\nAnd this should be an implementation restriction. After git-module\nbecomes a builtin,\nwe should cancel the limit. So it should be better to put the naming\nrestriction into\ngit-submodule.sh instead of the document.\n\n>\n>  In this bash script, there are many places which don't/can't handle\n>  names containing whitespace\n>  well. So the decaring a naming rule for the modue name sounds good.\n>\n>\n>\n>  --\n>  Ping Yin\n>\n\n\n\n-- \nPing Yin\n"}]}