{"thread":{"id":"36038","subject":"[PATCH] submodule : Add --no-separate-git-dir option to add and update command.","startedAt":"2014-03-03T14:47:46Z","lastAt":"2014-03-11T22:07:51Z","messageCount":16,"participants":["Henri GEIST","Jens Lehmann","Junio C Hamano","Heiko Voigt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"235877","messageId":"1393858066.7891.20.camel@Naugrim","threadId":"36038","inReplyTo":null,"subject":"[PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Henri GEIST","fromEmail":"geist.henri@laposte.net","sentAt":"2014-03-03T14:47:46Z","receivedAt":"2014-03-03T14:47:46Z","isPatch":true,"sender":{"key":"geist.henri@laposte.net","avatar":"https://avatars.githubusercontent.com/u/42912271?v=4"},"body":"This new option prevent git submodule <add|update> to clone the missing\nsubmodules with the --separate-git-dir option.\nThen the submodule will be regular repository and their gitdir will not\nbe placed in the superproject gitdir/modules directory.\n\nSigned-off-by: Henri GEIST <geist.henri@laposte.net>\n---\n Documentation/git-submodule.txt |   18 ++++++++++++++++--\n git-submodule.sh                |   22 ++++++++++++++++++++--\n t/t7400-submodule-basic.sh      |   12 ++++++++++++\n 3 files changed, 48 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 21cb59a..303a475 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -10,13 +10,14 @@ SYNOPSIS\n --------\n [verse]\n 'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>]\n-\t      [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]\n+\t      [--reference <repository>] [--depth <depth>] [--no-separate-git-dir]\n+\t      [--] <repository> [<path>]\n 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]\n 'git submodule' [--quiet] init [--] [<path>...]\n 'git submodule' [--quiet] deinit [-f|--force] [--] <path>...\n 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]\n \t      [-f|--force] [--rebase|--merge|--checkout] [--reference <repository>]\n-\t      [--depth <depth>] [--recursive] [--] [<path>...]\n+\t      [--depth <depth>] [--recursive] [--no-separate-git-dir] [--] [<path>...]\n 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]\n \t      [commit] [--] [<path>...]\n 'git submodule' [--quiet] foreach [--recursive] <command>\n@@ -107,6 +108,10 @@ is the superproject and submodule repositories will be kept\n together in the same relative location, and only the\n superproject's URL needs to be provided: git-submodule will correctly\n locate the submodule using the relative URL in .gitmodules.\n++\n+If `--no-separate-git-dir` is specified, missing submodules will be cloned\n+has normal git repository without the option `--separate-git-dir` pointing\n+to the modules directory of the superproject gitdir.\n \n status::\n \tShow the status of the submodules. This will print the SHA-1 of the\n@@ -185,6 +190,10 @@ If the submodule is not yet initialized, and you just want to use the\n setting as stored in .gitmodules, you can automatically initialize the\n submodule with the `--init` option.\n +\n+If `--no-separate-git-dir` is specified, missing submodules will be cloned\n+has normal git repository without the option `--separate-git-dir` pointing\n+to the modules directory of the superproject gitdir.\n++\n If `--recursive` is specified, this command will recurse into the\n registered submodules, and update any nested submodules within.\n +\n@@ -363,6 +372,11 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully.\n \tclone with a history truncated to the specified number of revisions.\n \tSee linkgit:git-clone[1]\n \n+--no-separate-git-dir::\n+\tThis option is valid for add and update commands. Specify that missing\n+\tsubmodules should be clonned as self contain repository without a\n+\tseparate gitdir placed in the modules directory of the superproject\n+\tgitdir.\n \n <path>...::\n \tPaths to submodule(s). When specified this will restrict the command\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex a33f68d..36eaf31 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -5,11 +5,11 @@\n # Copyright (c) 2007 Lars Hjemli\n \n dashless=$(basename \"$0\" | sed -e 's/-/ /')\n-USAGE=\"[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]\n+USAGE=\"[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--no-separate-git-dir] [--] <repository> [<path>]\n    or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]\n    or: $dashless [--quiet] init [--] [<path>...]\n    or: $dashless [--quiet] deinit [-f|--force] [--] <path>...\n-   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]\n+   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--no-separate-git-dir] [--] [<path>...]\n    or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]\n    or: $dashless [--quiet] foreach [--recursive] <command>\n    or: $dashless [--quiet] sync [--recursive] [--] [<path>...]\"\n@@ -36,6 +36,7 @@ update=\n prefix=\n custom_name=\n depth=\n+noseparategitdir=\n \n # The function takes at most 2 arguments. The first argument is the\n # URL that navigates to the submodule origin repo. When relative, this URL\n@@ -270,6 +271,17 @@ module_clone()\n \t\tquiet=-q\n \tfi\n \n+\n+\tif test -n \"$noseparategitdir\"\n+\tthen\n+\t\t(\n+\t\t\tclear_local_git_env\n+\t\t\tgit clone $quiet ${depth:+\"$depth\"} -n ${reference:+\"$reference\"} \"$url\" \"$sm_path\"\n+\t\t) ||\n+\t\tdie \"$(eval_gettext \"Clone of '\\$url' into submodule path '\\$sm_path' failed\")\"\n+\t\treturn\n+\tfi\n+\n \tgitdir=\n \tgitdir_base=\n \tbase_name=$(dirname \"$name\")\n@@ -359,6 +371,9 @@ cmd_add()\n \t\t-q|--quiet)\n \t\t\tGIT_QUIET=1\n \t\t\t;;\n+\t\t--no-separate-git-dir)\n+\t\t\tnoseparategitdir=1\n+\t\t\t;;\n \t\t--reference)\n \t\t\tcase \"$2\" in '') usage ;; esac\n \t\t\treference_path=$2\n@@ -758,6 +773,9 @@ cmd_update()\n \t\t-f|--force)\n \t\t\tforce=$1\n \t\t\t;;\n+\t\t--no-separate-git-dir)\n+\t\t\tnoseparategitdir=1\n+\t\t\t;;\n \t\t-r|--rebase)\n \t\t\tupdate=\"rebase\"\n \t\t\t;;\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex c28e8d8..aa2df3d 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -81,6 +81,18 @@ inspect() {\n \t)\n }\n \n+test_expect_success 'submodule add --no-separate-git-dir' '\n+\t(\n+\t\tcd addtest &&\n+\t\trm -rf submod &&\n+\t\tgit submodule add --no-separate-git-dir -q \"$submodurl\" submod >actual &&\n+\t\ttest_must_be_empty actual &&\n+\t\ttest -d submod/.git &&\n+\t\trm -rf submod &&\n+\t\tgit reset --hard\n+\t)\n+'\n+\n test_expect_success 'submodule add' '\n \techo \"refs/heads/master\" >expect &&\n \t>empty &&\n-- \n1.7.9.3.369.gd715.dirty\n"},{"id":"235888","messageId":"5314BFA5.2030807@web.de","threadId":"36038","inReplyTo":"1393858066.7891.20.camel@Naugrim","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-03T17:45:09Z","receivedAt":"2014-03-03T17:45:09Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 03.03.2014 14:47, schrieb Henri GEIST:\n> This new option prevent git submodule <add|update> to clone the missing\n> submodules with the --separate-git-dir option.\n> Then the submodule will be regular repository and their gitdir will not\n> be placed in the superproject gitdir/modules directory.\n\nAnd what is your motivation for this? After all submodules containing\na .git directory are second class citizens (because they can never be\nsafely removed by regular git commands).\n\n> Signed-off-by: Henri GEIST <geist.henri@laposte.net>\n> ---\n>  Documentation/git-submodule.txt |   18 ++++++++++++++++--\n>  git-submodule.sh                |   22 ++++++++++++++++++++--\n>  t/t7400-submodule-basic.sh      |   12 ++++++++++++\n>  3 files changed, 48 insertions(+), 4 deletions(-)\n> \n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index 21cb59a..303a475 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -10,13 +10,14 @@ SYNOPSIS\n>  --------\n>  [verse]\n>  'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>]\n> -\t      [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]\n> +\t      [--reference <repository>] [--depth <depth>] [--no-separate-git-dir]\n> +\t      [--] <repository> [<path>]\n>  'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]\n>  'git submodule' [--quiet] init [--] [<path>...]\n>  'git submodule' [--quiet] deinit [-f|--force] [--] <path>...\n>  'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]\n>  \t      [-f|--force] [--rebase|--merge|--checkout] [--reference <repository>]\n> -\t      [--depth <depth>] [--recursive] [--] [<path>...]\n> +\t      [--depth <depth>] [--recursive] [--no-separate-git-dir] [--] [<path>...]\n>  'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]\n>  \t      [commit] [--] [<path>...]\n>  'git submodule' [--quiet] foreach [--recursive] <command>\n> @@ -107,6 +108,10 @@ is the superproject and submodule repositories will be kept\n>  together in the same relative location, and only the\n>  superproject's URL needs to be provided: git-submodule will correctly\n>  locate the submodule using the relative URL in .gitmodules.\n> ++\n> +If `--no-separate-git-dir` is specified, missing submodules will be cloned\n> +has normal git repository without the option `--separate-git-dir` pointing\n> +to the modules directory of the superproject gitdir.\n>  \n>  status::\n>  \tShow the status of the submodules. This will print the SHA-1 of the\n> @@ -185,6 +190,10 @@ If the submodule is not yet initialized, and you just want to use the\n>  setting as stored in .gitmodules, you can automatically initialize the\n>  submodule with the `--init` option.\n>  +\n> +If `--no-separate-git-dir` is specified, missing submodules will be cloned\n> +has normal git repository without the option `--separate-git-dir` pointing\n> +to the modules directory of the superproject gitdir.\n> ++\n>  If `--recursive` is specified, this command will recurse into the\n>  registered submodules, and update any nested submodules within.\n>  +\n> @@ -363,6 +372,11 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully.\n>  \tclone with a history truncated to the specified number of revisions.\n>  \tSee linkgit:git-clone[1]\n>  \n> +--no-separate-git-dir::\n> +\tThis option is valid for add and update commands. Specify that missing\n> +\tsubmodules should be clonned as self contain repository without a\n> +\tseparate gitdir placed in the modules directory of the superproject\n> +\tgitdir.\n>  \n>  <path>...::\n>  \tPaths to submodule(s). When specified this will restrict the command\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index a33f68d..36eaf31 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -5,11 +5,11 @@\n>  # Copyright (c) 2007 Lars Hjemli\n>  \n>  dashless=$(basename \"$0\" | sed -e 's/-/ /')\n> -USAGE=\"[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]\n> +USAGE=\"[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--no-separate-git-dir] [--] <repository> [<path>]\n>     or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]\n>     or: $dashless [--quiet] init [--] [<path>...]\n>     or: $dashless [--quiet] deinit [-f|--force] [--] <path>...\n> -   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]\n> +   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--no-separate-git-dir] [--] [<path>...]\n>     or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]\n>     or: $dashless [--quiet] foreach [--recursive] <command>\n>     or: $dashless [--quiet] sync [--recursive] [--] [<path>...]\"\n> @@ -36,6 +36,7 @@ update=\n>  prefix=\n>  custom_name=\n>  depth=\n> +noseparategitdir=\n>  \n>  # The function takes at most 2 arguments. The first argument is the\n>  # URL that navigates to the submodule origin repo. When relative, this URL\n> @@ -270,6 +271,17 @@ module_clone()\n>  \t\tquiet=-q\n>  \tfi\n>  \n> +\n> +\tif test -n \"$noseparategitdir\"\n> +\tthen\n> +\t\t(\n> +\t\t\tclear_local_git_env\n> +\t\t\tgit clone $quiet ${depth:+\"$depth\"} -n ${reference:+\"$reference\"} \"$url\" \"$sm_path\"\n> +\t\t) ||\n> +\t\tdie \"$(eval_gettext \"Clone of '\\$url' into submodule path '\\$sm_path' failed\")\"\n> +\t\treturn\n> +\tfi\n> +\n>  \tgitdir=\n>  \tgitdir_base=\n>  \tbase_name=$(dirname \"$name\")\n> @@ -359,6 +371,9 @@ cmd_add()\n>  \t\t-q|--quiet)\n>  \t\t\tGIT_QUIET=1\n>  \t\t\t;;\n> +\t\t--no-separate-git-dir)\n> +\t\t\tnoseparategitdir=1\n> +\t\t\t;;\n>  \t\t--reference)\n>  \t\t\tcase \"$2\" in '') usage ;; esac\n>  \t\t\treference_path=$2\n> @@ -758,6 +773,9 @@ cmd_update()\n>  \t\t-f|--force)\n>  \t\t\tforce=$1\n>  \t\t\t;;\n> +\t\t--no-separate-git-dir)\n> +\t\t\tnoseparategitdir=1\n> +\t\t\t;;\n>  \t\t-r|--rebase)\n>  \t\t\tupdate=\"rebase\"\n>  \t\t\t;;\n> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\n> index c28e8d8..aa2df3d 100755\n> --- a/t/t7400-submodule-basic.sh\n> +++ b/t/t7400-submodule-basic.sh\n> @@ -81,6 +81,18 @@ inspect() {\n>  \t)\n>  }\n>  \n> +test_expect_success 'submodule add --no-separate-git-dir' '\n> +\t(\n> +\t\tcd addtest &&\n> +\t\trm -rf submod &&\n> +\t\tgit submodule add --no-separate-git-dir -q \"$submodurl\" submod >actual &&\n> +\t\ttest_must_be_empty actual &&\n> +\t\ttest -d submod/.git &&\n> +\t\trm -rf submod &&\n> +\t\tgit reset --hard\n> +\t)\n> +'\n> +\n>  test_expect_success 'submodule add' '\n>  \techo \"refs/heads/master\" >expect &&\n>  \t>empty &&\n> \n"},{"id":"235908","messageId":"xmqqmwh7ozn4.fsf@gitster.dls.corp.google.com","threadId":"36038","inReplyTo":"1393858066.7891.20.camel@Naugrim","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-03T19:22:55Z","receivedAt":"2014-03-03T19:22:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"[CC'ing the submodule area experts.]\n\nHenri GEIST <geist.henri@laposte.net> writes:\n\n> This new option prevent git submodule <add|update> to clone the missing\n> submodules with the --separate-git-dir option.\n> Then the submodule will be regular repository and their gitdir will not\n> be placed in the superproject gitdir/modules directory.\n>\n> Signed-off-by: Henri GEIST <geist.henri@laposte.net>\n> ---\n\nThanks.\n\nThe above describes what the new option does, but does not explain\nwhy the new option is a good idea in the first place.\n\nGiven that we used to directly clone into the superproject's working\ntree like this patch does, realized that it was a very bad idea and\nare trying to move to the direction of keeping it in modules/\nsubdirectory of the superproject's .git directory, there needs to be\na very good explanation to justify why this \"going backwards\" is\nsometimes a desirable thing.\n"},{"id":"235918","messageId":"1393878866.7891.22.camel@Naugrim","threadId":"36038","inReplyTo":"5314BFA5.2030807@web.de","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Henri GEIST","fromEmail":"geist.henri@laposte.net","sentAt":"2014-03-03T20:34:26Z","receivedAt":"2014-03-03T20:34:26Z","isPatch":true,"sender":{"key":"geist.henri@laposte.net","avatar":"https://avatars.githubusercontent.com/u/42912271?v=4"},"body":"Le lundi 03 mars 2014 à 17:45 +0000, Jens Lehmann a écrit :\n> Am 03.03.2014 14:47, schrieb Henri GEIST:\n> > This new option prevent git submodule <add|update> to clone the missing\n> > submodules with the --separate-git-dir option.\n> > Then the submodule will be regular repository and their gitdir will not\n> > be placed in the superproject gitdir/modules directory.\n> \n> And what is your motivation for this? After all submodules containing\n> a .git directory are second class citizens (because they can never be\n> safely removed by regular git commands).\n>\n\nI recognize most people will prefer to have the .git directory separate.\nAnd I do not intend to make this option the default.\n\nMy reasons are:\n\n  - As it is not clearly stated in the doc that the gitdir is separate.\n    The first time I have copied one module to an USB key I had a big\n    surprise.\n\n  - This will not change anything for people not using it.\n\n  - I use an other patch which I plane to send later which enable multiple\n    level of superproject to add a gitlink to the same submodule.\n    And in this case the superproject containing the separate gitdir will be\n    arbitrary and depend on the processing order of the\n    'git submodule update --recursive' command.\n\n  - I have written this for myself and have using it since 2012 and send it in\n    the hope it could be useful for someone else even if it is only a few\n    people. But if its not the case no problem I will keep using it for myself.\n\n\n> > Signed-off-by: Henri GEIST <geist.henri@laposte.net>\n> > ---\n> >  Documentation/git-submodule.txt |   18 ++++++++++++++++--\n> >  git-submodule.sh                |   22 ++++++++++++++++++++--\n> >  t/t7400-submodule-basic.sh      |   12 ++++++++++++\n> >  3 files changed, 48 insertions(+), 4 deletions(-)\n> > \n> > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> > index 21cb59a..303a475 100644\n> > --- a/Documentation/git-submodule.txt\n> > +++ b/Documentation/git-submodule.txt\n> > @@ -10,13 +10,14 @@ SYNOPSIS\n> >  --------\n> >  [verse]\n> >  'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>]\n> > -\t      [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]\n> > +\t      [--reference <repository>] [--depth <depth>] [--no-separate-git-dir]\n> > +\t      [--] <repository> [<path>]\n> >  'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]\n> >  'git submodule' [--quiet] init [--] [<path>...]\n> >  'git submodule' [--quiet] deinit [-f|--force] [--] <path>...\n> >  'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]\n> >  \t      [-f|--force] [--rebase|--merge|--checkout] [--reference <repository>]\n> > -\t      [--depth <depth>] [--recursive] [--] [<path>...]\n> > +\t      [--depth <depth>] [--recursive] [--no-separate-git-dir] [--] [<path>...]\n> >  'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]\n> >  \t      [commit] [--] [<path>...]\n> >  'git submodule' [--quiet] foreach [--recursive] <command>\n> > @@ -107,6 +108,10 @@ is the superproject and submodule repositories will be kept\n> >  together in the same relative location, and only the\n> >  superproject's URL needs to be provided: git-submodule will correctly\n> >  locate the submodule using the relative URL in .gitmodules.\n> > ++\n> > +If `--no-separate-git-dir` is specified, missing submodules will be cloned\n> > +has normal git repository without the option `--separate-git-dir` pointing\n> > +to the modules directory of the superproject gitdir.\n> >  \n> >  status::\n> >  \tShow the status of the submodules. This will print the SHA-1 of the\n> > @@ -185,6 +190,10 @@ If the submodule is not yet initialized, and you just want to use the\n> >  setting as stored in .gitmodules, you can automatically initialize the\n> >  submodule with the `--init` option.\n> >  +\n> > +If `--no-separate-git-dir` is specified, missing submodules will be cloned\n> > +has normal git repository without the option `--separate-git-dir` pointing\n> > +to the modules directory of the superproject gitdir.\n> > ++\n> >  If `--recursive` is specified, this command will recurse into the\n> >  registered submodules, and update any nested submodules within.\n> >  +\n> > @@ -363,6 +372,11 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully.\n> >  \tclone with a history truncated to the specified number of revisions.\n> >  \tSee linkgit:git-clone[1]\n> >  \n> > +--no-separate-git-dir::\n> > +\tThis option is valid for add and update commands. Specify that missing\n> > +\tsubmodules should be clonned as self contain repository without a\n> > +\tseparate gitdir placed in the modules directory of the superproject\n> > +\tgitdir.\n> >  \n> >  <path>...::\n> >  \tPaths to submodule(s). When specified this will restrict the command\n> > diff --git a/git-submodule.sh b/git-submodule.sh\n> > index a33f68d..36eaf31 100755\n> > --- a/git-submodule.sh\n> > +++ b/git-submodule.sh\n> > @@ -5,11 +5,11 @@\n> >  # Copyright (c) 2007 Lars Hjemli\n> >  \n> >  dashless=$(basename \"$0\" | sed -e 's/-/ /')\n> > -USAGE=\"[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]\n> > +USAGE=\"[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--no-separate-git-dir] [--] <repository> [<path>]\n> >     or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]\n> >     or: $dashless [--quiet] init [--] [<path>...]\n> >     or: $dashless [--quiet] deinit [-f|--force] [--] <path>...\n> > -   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]\n> > +   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--no-separate-git-dir] [--] [<path>...]\n> >     or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]\n> >     or: $dashless [--quiet] foreach [--recursive] <command>\n> >     or: $dashless [--quiet] sync [--recursive] [--] [<path>...]\"\n> > @@ -36,6 +36,7 @@ update=\n> >  prefix=\n> >  custom_name=\n> >  depth=\n> > +noseparategitdir=\n> >  \n> >  # The function takes at most 2 arguments. The first argument is the\n> >  # URL that navigates to the submodule origin repo. When relative, this URL\n> > @@ -270,6 +271,17 @@ module_clone()\n> >  \t\tquiet=-q\n> >  \tfi\n> >  \n> > +\n> > +\tif test -n \"$noseparategitdir\"\n> > +\tthen\n> > +\t\t(\n> > +\t\t\tclear_local_git_env\n> > +\t\t\tgit clone $quiet ${depth:+\"$depth\"} -n ${reference:+\"$reference\"} \"$url\" \"$sm_path\"\n> > +\t\t) ||\n> > +\t\tdie \"$(eval_gettext \"Clone of '\\$url' into submodule path '\\$sm_path' failed\")\"\n> > +\t\treturn\n> > +\tfi\n> > +\n> >  \tgitdir=\n> >  \tgitdir_base=\n> >  \tbase_name=$(dirname \"$name\")\n> > @@ -359,6 +371,9 @@ cmd_add()\n> >  \t\t-q|--quiet)\n> >  \t\t\tGIT_QUIET=1\n> >  \t\t\t;;\n> > +\t\t--no-separate-git-dir)\n> > +\t\t\tnoseparategitdir=1\n> > +\t\t\t;;\n> >  \t\t--reference)\n> >  \t\t\tcase \"$2\" in '') usage ;; esac\n> >  \t\t\treference_path=$2\n> > @@ -758,6 +773,9 @@ cmd_update()\n> >  \t\t-f|--force)\n> >  \t\t\tforce=$1\n> >  \t\t\t;;\n> > +\t\t--no-separate-git-dir)\n> > +\t\t\tnoseparategitdir=1\n> > +\t\t\t;;\n> >  \t\t-r|--rebase)\n> >  \t\t\tupdate=\"rebase\"\n> >  \t\t\t;;\n> > diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\n> > index c28e8d8..aa2df3d 100755\n> > --- a/t/t7400-submodule-basic.sh\n> > +++ b/t/t7400-submodule-basic.sh\n> > @@ -81,6 +81,18 @@ inspect() {\n> >  \t)\n> >  }\n> >  \n> > +test_expect_success 'submodule add --no-separate-git-dir' '\n> > +\t(\n> > +\t\tcd addtest &&\n> > +\t\trm -rf submod &&\n> > +\t\tgit submodule add --no-separate-git-dir -q \"$submodurl\" submod >actual &&\n> > +\t\ttest_must_be_empty actual &&\n> > +\t\ttest -d submod/.git &&\n> > +\t\trm -rf submod &&\n> > +\t\tgit reset --hard\n> > +\t)\n> > +'\n> > +\n> >  test_expect_success 'submodule add' '\n> >  \techo \"refs/heads/master\" >expect &&\n> >  \t>empty &&\n> > \n> \n\n\n\n"},{"id":"236104","messageId":"53176951.7000201@web.de","threadId":"36038","inReplyTo":"1393878866.7891.22.camel@Naugrim","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-05T18:13:37Z","receivedAt":"2014-03-05T18:13:37Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 03.03.2014 21:34, schrieb Henri GEIST:\n> Le lundi 03 mars 2014 à 17:45 +0000, Jens Lehmann a écrit :\n>> Am 03.03.2014 14:47, schrieb Henri GEIST:\n>>> This new option prevent git submodule <add|update> to clone the missing\n>>> submodules with the --separate-git-dir option.\n>>> Then the submodule will be regular repository and their gitdir will not\n>>> be placed in the superproject gitdir/modules directory.\n>>\n>> And what is your motivation for this? After all submodules containing\n>> a .git directory are second class citizens (because they can never be\n>> safely removed by regular git commands).\n>>\n> \n> I recognize most people will prefer to have the .git directory separate.\n> And I do not intend to make this option the default.\n> \n> My reasons are:\n> \n>   - As it is not clearly stated in the doc that the gitdir is separate.\n>     The first time I have copied one module to an USB key I had a big\n>     surprise.\n\nOops! Could you please help us by hinting how the documentation\ncould be improved here?\n\n>   - This will not change anything for people not using it.\n\nI do not agree, as they'll be seeing a new option and might use\nit to \"go backward\" as Junio explained in his answer.\n\n>   - I use an other patch which I plane to send later which enable multiple\n>     level of superproject to add a gitlink to the same submodule.\n>     And in this case the superproject containing the separate gitdir will be\n>     arbitrary and depend on the processing order of the\n>     'git submodule update --recursive' command.\n\nI don't understand that. How is that different from using different\nnames (and thus different separate gitdirs) for that duplicated\nsubmodule? After all, the .git directory is just moved somewhere\nelse in the superproject's work tree, and as the name defaults to\nthe path of the submodule ...\n\n>   - I have written this for myself and have using it since 2012 and send it in\n>     the hope it could be useful for someone else even if it is only a few\n>     people. But if its not the case no problem I will keep using it for myself.\n\nThanks.\n"},{"id":"236145","messageId":"1394069128.7891.29.camel@Naugrim","threadId":"36038","inReplyTo":"53176951.7000201@web.de","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Henri GEIST","fromEmail":"geist.henri@laposte.net","sentAt":"2014-03-06T01:25:28Z","receivedAt":"2014-03-06T01:25:28Z","isPatch":true,"sender":{"key":"geist.henri@laposte.net","avatar":"https://avatars.githubusercontent.com/u/42912271?v=4"},"body":"Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :\n> Am 03.03.2014 21:34, schrieb Henri GEIST:\n> > Le lundi 03 mars 2014 à 17:45 +0000, Jens Lehmann a écrit :\n> >> Am 03.03.2014 14:47, schrieb Henri GEIST:\n> >>> This new option prevent git submodule <add|update> to clone the missing\n> >>> submodules with the --separate-git-dir option.\n> >>> Then the submodule will be regular repository and their gitdir will not\n> >>> be placed in the superproject gitdir/modules directory.\n> >>\n> >> And what is your motivation for this? After all submodules containing\n> >> a .git directory are second class citizens (because they can never be\n> >> safely removed by regular git commands).\n> >>\n> > \n> > I recognize most people will prefer to have the .git directory separate.\n> > And I do not intend to make this option the default.\n> > \n> > My reasons are:\n> > \n> >   - As it is not clearly stated in the doc that the gitdir is separate.\n> >     The first time I have copied one module to an USB key I had a big\n> >     surprise.\n> \n> Oops! Could you please help us by hinting how the documentation\n> could be improved here?\n> \n\nOf course.\nThere is nothing in Documentation/git-submodule.txt to inform that submodules\nclones are different from regular clones.\nI will write and propose a patch for the documentation.\nBut maybe in a new thread.\n\n\n> >   - This will not change anything for people not using it.\n> \n> I do not agree, as they'll be seeing a new option and might use\n> it to \"go backward\" as Junio explained in his answer.\n> \n> >   - I use an other patch which I plane to send later which enable multiple\n> >     level of superproject to add a gitlink to the same submodule.\n> >     And in this case the superproject containing the separate gitdir will be\n> >     arbitrary and depend on the processing order of the\n> >     'git submodule update --recursive' command.\n> \n> I don't understand that. How is that different from using different\n> names (and thus different separate gitdirs) for that duplicated\n> submodule? After all, the .git directory is just moved somewhere\n> else in the superproject's work tree, and as the name defaults to\n> the path of the submodule ...\n> \n\nI think I should give an example.\nIf I have a hierarchy like this :\n\nsuperproject/submodule/subsubmodule\n\nWhat I often do is:\n\nsuperproject --> submodule --> subsubmodule\n             |                 ^\n             '-----------------'\n\nWhere '-->' is a gitlink.\n\n\nThat mean .gitmodules and index of the superproject contain both submodule and\nsubmodule/subsubmodule.\nAnd also mean (and that is the point) subsubmodule is a direct 'child' of both\nsuperproject and submodule.\nIn this case where should the separate gitdir of subsubmodule be placed ?\n  - In superproject/modules/submodule/subsubmodule ?\n  - In superproject/submodule/modules/subsubmodule ?\n  - Depending on the 'git submodule update' command order ?\n  - Or both ?\n\n\n> >   - I have written this for myself and have using it since 2012 and send it in\n> >     the hope it could be useful for someone else even if it is only a few\n> >     people. But if its not the case no problem I will keep using it for myself.\n> \n> Thanks.\n\n\n\n"},{"id":"236190","messageId":"5318D101.9050305@web.de","threadId":"36038","inReplyTo":"1394069128.7891.29.camel@Naugrim","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-06T19:48:17Z","receivedAt":"2014-03-06T19:48:17Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 06.03.2014 02:25, schrieb Henri GEIST:\n> Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :\n>> Am 03.03.2014 21:34, schrieb Henri GEIST:\n>>> Le lundi 03 mars 2014 à 17:45 +0000, Jens Lehmann a écrit :\n>>>> Am 03.03.2014 14:47, schrieb Henri GEIST:\n>>>>> This new option prevent git submodule <add|update> to clone the missing\n>>>>> submodules with the --separate-git-dir option.\n>>>>> Then the submodule will be regular repository and their gitdir will not\n>>>>> be placed in the superproject gitdir/modules directory.\n>>>>\n>>>> And what is your motivation for this? After all submodules containing\n>>>> a .git directory are second class citizens (because they can never be\n>>>> safely removed by regular git commands).\n>>>>\n>>>\n>>> I recognize most people will prefer to have the .git directory separate.\n>>> And I do not intend to make this option the default.\n>>>\n>>> My reasons are:\n>>>\n>>>   - As it is not clearly stated in the doc that the gitdir is separate.\n>>>     The first time I have copied one module to an USB key I had a big\n>>>     surprise.\n>>\n>> Oops! Could you please help us by hinting how the documentation\n>> could be improved here?\n>>\n> \n> Of course.\n> There is nothing in Documentation/git-submodule.txt to inform that submodules\n> clones are different from regular clones.\n> I will write and propose a patch for the documentation.\n> But maybe in a new thread.\n\nThanks!\n\n>>>   - This will not change anything for people not using it.\n>>\n>> I do not agree, as they'll be seeing a new option and might use\n>> it to \"go backward\" as Junio explained in his answer.\n>>\n>>>   - I use an other patch which I plane to send later which enable multiple\n>>>     level of superproject to add a gitlink to the same submodule.\n>>>     And in this case the superproject containing the separate gitdir will be\n>>>     arbitrary and depend on the processing order of the\n>>>     'git submodule update --recursive' command.\n>>\n>> I don't understand that. How is that different from using different\n>> names (and thus different separate gitdirs) for that duplicated\n>> submodule? After all, the .git directory is just moved somewhere\n>> else in the superproject's work tree, and as the name defaults to\n>> the path of the submodule ...\n>>\n> \n> I think I should give an example.\n> If I have a hierarchy like this :\n> \n> superproject/submodule/subsubmodule\n> \n> What I often do is:\n> \n> superproject --> submodule --> subsubmodule\n>              |                 ^\n>              '-----------------'\n> \n> Where '-->' is a gitlink.\n> \n> \n> That mean .gitmodules and index of the superproject contain both submodule and\n> submodule/subsubmodule.\n\nWow, that shouldn't even work (as everything inside \"submodule\"\nshouldn't be part of the superproject but must be contained in\nthe submodule itself). Do the \"git submodule\" script and other\ngit commands like \"git status\" work for you in such setups?\n\n> And also mean (and that is the point) subsubmodule is a direct 'child' of both\n> superproject and submodule.\n\nWhich I think should not be possible. If that works with current\nGit I suspect we have a bug to fix ... or does your other patch\nmake this work?\n\n> In this case where should the separate gitdir of subsubmodule be placed ?\n>   - In superproject/modules/submodule/subsubmodule ?\n>   - In superproject/submodule/modules/subsubmodule ?\n>   - Depending on the 'git submodule update' command order ?\n>   - Or both ?\n\nIt should be placed in .git/modules/submodule/modules/subsubmodule\nof the superproject (assuming the subsubmodule is part of the first\nlevel submodule). But in your example that would live in\n.git/modules/submodule/subsubmodule (but as mentioned above, I do\nnot consider this a valid setup because then two repositories would\nbe responsible for the data inside subsubmodule, which will lead to\nlots of trouble).\n"},{"id":"236192","messageId":"1394136925.7891.31.camel@Naugrim","threadId":"36038","inReplyTo":"5318D101.9050305@web.de","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Henri GEIST","fromEmail":"geist.henri@laposte.net","sentAt":"2014-03-06T20:15:25Z","receivedAt":"2014-03-06T20:15:25Z","isPatch":true,"sender":{"key":"geist.henri@laposte.net","avatar":"https://avatars.githubusercontent.com/u/42912271?v=4"},"body":"Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :\n> Am 06.03.2014 02:25, schrieb Henri GEIST:\n> > Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :\n> >> Am 03.03.2014 21:34, schrieb Henri GEIST:\n> >>> Le lundi 03 mars 2014 à 17:45 +0000, Jens Lehmann a écrit :\n> >>>> Am 03.03.2014 14:47, schrieb Henri GEIST:\n> >>>>> This new option prevent git submodule <add|update> to clone the missing\n> >>>>> submodules with the --separate-git-dir option.\n> >>>>> Then the submodule will be regular repository and their gitdir will not\n> >>>>> be placed in the superproject gitdir/modules directory.\n> >>>>\n> >>>> And what is your motivation for this? After all submodules containing\n> >>>> a .git directory are second class citizens (because they can never be\n> >>>> safely removed by regular git commands).\n> >>>>\n> >>>\n> >>> I recognize most people will prefer to have the .git directory separate.\n> >>> And I do not intend to make this option the default.\n> >>>\n> >>> My reasons are:\n> >>>\n> >>>   - As it is not clearly stated in the doc that the gitdir is separate.\n> >>>     The first time I have copied one module to an USB key I had a big\n> >>>     surprise.\n> >>\n> >> Oops! Could you please help us by hinting how the documentation\n> >> could be improved here?\n> >>\n> > \n> > Of course.\n> > There is nothing in Documentation/git-submodule.txt to inform that submodules\n> > clones are different from regular clones.\n> > I will write and propose a patch for the documentation.\n> > But maybe in a new thread.\n> \n> Thanks!\n> \n> >>>   - This will not change anything for people not using it.\n> >>\n> >> I do not agree, as they'll be seeing a new option and might use\n> >> it to \"go backward\" as Junio explained in his answer.\n> >>\n> >>>   - I use an other patch which I plane to send later which enable multiple\n> >>>     level of superproject to add a gitlink to the same submodule.\n> >>>     And in this case the superproject containing the separate gitdir will be\n> >>>     arbitrary and depend on the processing order of the\n> >>>     'git submodule update --recursive' command.\n> >>\n> >> I don't understand that. How is that different from using different\n> >> names (and thus different separate gitdirs) for that duplicated\n> >> submodule? After all, the .git directory is just moved somewhere\n> >> else in the superproject's work tree, and as the name defaults to\n> >> the path of the submodule ...\n> >>\n> > \n> > I think I should give an example.\n> > If I have a hierarchy like this :\n> > \n> > superproject/submodule/subsubmodule\n> > \n> > What I often do is:\n> > \n> > superproject --> submodule --> subsubmodule\n> >              |                 ^\n> >              '-----------------'\n> > \n> > Where '-->' is a gitlink.\n> > \n> > \n> > That mean .gitmodules and index of the superproject contain both submodule and\n> > submodule/subsubmodule.\n> \n> Wow, that shouldn't even work (as everything inside \"submodule\"\n> shouldn't be part of the superproject but must be contained in\n> the submodule itself). Do the \"git submodule\" script and other\n> git commands like \"git status\" work for you in such setups?\n>\n\nAs I stated above it is the purpose of the other patch that I have not already send\nto implement this behavior. And that is why it work.\nEverything including 'git submodule' and 'git status' work perfectly.\nThe intent of this patch is only to permit this for gitlinks. Not for regular files.\n \n> > and also mean (and that is the point) subsubmodule is a direct 'child' of both\n> > superproject and submodule.\n> \n> Which I think should not be possible. If that works with current\n> Git I suspect we have a bug to fix ... or does your other patch\n> make this work?\n\nYou have no bug on this point without my modification this is not possible.\n\n> \n> > In this case where should the separate gitdir of subsubmodule be placed ?\n> >   - In superproject/modules/submodule/subsubmodule ?\n> >   - In superproject/submodule/modules/subsubmodule ?\n> >   - Depending on the 'git submodule update' command order ?\n> >   - Or both ?\n> \n> It should be placed in .git/modules/submodule/modules/subsubmodule\n> of the superproject (assuming the subsubmodule is part of the first\n> level submodule). But in your example that would live in\n> .git/modules/submodule/subsubmodule (but as mentioned above, I do\n> not consider this a valid setup because then two repositories would\n> be responsible for the data inside subsubmodule, which will lead to\n> lots of trouble).\n\nThat is why a had proposed an option '--no-separate-git-dir'\nfor 'git submodule <add|update>' then no repository is responsible for the data\nin subsubmodule except subsubmodule itself.\n\n\n"},{"id":"236196","messageId":"5318DFDD.4060006@web.de","threadId":"36038","inReplyTo":"1394136925.7891.31.camel@Naugrim","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-06T20:51:41Z","receivedAt":"2014-03-06T20:51:41Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 06.03.2014 21:15, schrieb Henri GEIST:\n> Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :\n>> Am 06.03.2014 02:25, schrieb Henri GEIST:\n>>> Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :\n>>>> Am 03.03.2014 21:34, schrieb Henri GEIST:\n>>>>>   - I use an other patch which I plane to send later which enable multiple\n>>>>>     level of superproject to add a gitlink to the same submodule.\n>>>>>     And in this case the superproject containing the separate gitdir will be\n>>>>>     arbitrary and depend on the processing order of the\n>>>>>     'git submodule update --recursive' command.\n>>>>\n>>>> I don't understand that. How is that different from using different\n>>>> names (and thus different separate gitdirs) for that duplicated\n>>>> submodule? After all, the .git directory is just moved somewhere\n>>>> else in the superproject's work tree, and as the name defaults to\n>>>> the path of the submodule ...\n>>>\n>>> I think I should give an example.\n>>> If I have a hierarchy like this :\n>>>\n>>> superproject/submodule/subsubmodule\n>>>\n>>> What I often do is:\n>>>\n>>> superproject --> submodule --> subsubmodule\n>>>              |                 ^\n>>>              '-----------------'\n>>>\n>>> Where '-->' is a gitlink.\n>>>\n>>>\n>>> That mean .gitmodules and index of the superproject contain both submodule and\n>>> submodule/subsubmodule.\n>>\n>> Wow, that shouldn't even work (as everything inside \"submodule\"\n>> shouldn't be part of the superproject but must be contained in\n>> the submodule itself). Do the \"git submodule\" script and other\n>> git commands like \"git status\" work for you in such setups?\n> \n> As I stated above it is the purpose of the other patch that I have not already send\n> to implement this behavior. And that is why it work.\n\nOk.\n\n> Everything including 'git submodule' and 'git status' work perfectly.\n> The intent of this patch is only to permit this for gitlinks. Not for regular files.\n\nBut I still believe that this shouldn't be permitted at all,\nno matter if files or submodules are concerned. The pitfalls\nfiles face in such a scenario are pretty much the same for\nsubmodules too.\n\n>>> and also mean (and that is the point) subsubmodule is a direct 'child' of both\n>>> superproject and submodule.\n>>\n>> Which I think should not be possible. If that works with current\n>> Git I suspect we have a bug to fix ... or does your other patch\n>> make this work?\n> \n> You have no bug on this point without my modification this is not possible.\n\nGlad to hear that.\n\n>>> In this case where should the separate gitdir of subsubmodule be placed ?\n>>>   - In superproject/modules/submodule/subsubmodule ?\n>>>   - In superproject/submodule/modules/subsubmodule ?\n>>>   - Depending on the 'git submodule update' command order ?\n>>>   - Or both ?\n>>\n>> It should be placed in .git/modules/submodule/modules/subsubmodule\n>> of the superproject (assuming the subsubmodule is part of the first\n>> level submodule). But in your example that would live in\n>> .git/modules/submodule/subsubmodule (but as mentioned above, I do\n>> not consider this a valid setup because then two repositories would\n>> be responsible for the data inside subsubmodule, which will lead to\n>> lots of trouble).\n> \n> That is why a had proposed an option '--no-separate-git-dir'\n> for 'git submodule <add|update>' then no repository is responsible for the data\n> in subsubmodule except subsubmodule itself.\n\nAs I mentioned in my other email, it doesn't matter at all for\nthe setup you're describing if the git directory lives under\n.git/modules of the superproject or in a .git directory in the\nsubmodule. The problem you're creating with your future patch\nis related to the work tree, not the GIT_DIR: \"subsubmodule\"\ncould also be added to and tracked by \"submodule\" (as that is\ncompletely unaware of \"subsubmodule\" already being tracked by\nthe superproject). Then you would end up in real trouble, as\n\"superproject\" and \"submodule\" could have differing SHA-1s\nrecorded for subsubmodule. Don't go there, for just the same\nreasons we do not allow that for files.\n\nWhat is the use case you are trying to solve and why can that\nnot be handled by adding \"subsubmodule\" inside \"submodule\"?\n"},{"id":"236213","messageId":"1394144428.7891.33.camel@Naugrim","threadId":"36038","inReplyTo":"5318DFDD.4060006@web.de","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Henri GEIST","fromEmail":"geist.henri@laposte.net","sentAt":"2014-03-06T22:20:28Z","receivedAt":"2014-03-06T22:20:28Z","isPatch":true,"sender":{"key":"geist.henri@laposte.net","avatar":"https://avatars.githubusercontent.com/u/42912271?v=4"},"body":"Le jeudi 06 mars 2014 à 21:51 +0100, Jens Lehmann a écrit :\n> Am 06.03.2014 21:15, schrieb Henri GEIST:\n> > Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :\n> >> Am 06.03.2014 02:25, schrieb Henri GEIST:\n> >>> Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :\n> >>>> Am 03.03.2014 21:34, schrieb Henri GEIST:\n> >>>>>   - I use an other patch which I plane to send later which enable multiple\n> >>>>>     level of superproject to add a gitlink to the same submodule.\n> >>>>>     And in this case the superproject containing the separate gitdir will be\n> >>>>>     arbitrary and depend on the processing order of the\n> >>>>>     'git submodule update --recursive' command.\n> >>>>\n> >>>> I don't understand that. How is that different from using different\n> >>>> names (and thus different separate gitdirs) for that duplicated\n> >>>> submodule? After all, the .git directory is just moved somewhere\n> >>>> else in the superproject's work tree, and as the name defaults to\n> >>>> the path of the submodule ...\n> >>>\n> >>> I think I should give an example.\n> >>> If I have a hierarchy like this :\n> >>>\n> >>> superproject/submodule/subsubmodule\n> >>>\n> >>> What I often do is:\n> >>>\n> >>> superproject --> submodule --> subsubmodule\n> >>>              |                 ^\n> >>>              '-----------------'\n> >>>\n> >>> Where '-->' is a gitlink.\n> >>>\n> >>>\n> >>> That mean .gitmodules and index of the superproject contain both submodule and\n> >>> submodule/subsubmodule.\n> >>\n> >> Wow, that shouldn't even work (as everything inside \"submodule\"\n> >> shouldn't be part of the superproject but must be contained in\n> >> the submodule itself). Do the \"git submodule\" script and other\n> >> git commands like \"git status\" work for you in such setups?\n> > \n> > As I stated above it is the purpose of the other patch that I have not already send\n> > to implement this behavior. And that is why it work.\n> \n> Ok.\n> \n> > Everything including 'git submodule' and 'git status' work perfectly.\n> > The intent of this patch is only to permit this for gitlinks. Not for regular files.\n> \n> But I still believe that this shouldn't be permitted at all,\n> no matter if files or submodules are concerned. The pitfalls\n> files face in such a scenario are pretty much the same for\n> submodules too.\n>\n\nMay be you have a good argument for this belief ?\n\nAs for the difference between submodules and regular files\nthe only difference is in the meaning.\nTechnically directory are just a special kind of file.\nBut there day to day use is drastically different of\nthe use of files which are not directories.\nI am not against enabling it for files as well.\nI am just unable to imagine a case where it make sens.\nA possible solution when someone try to do it is to issue a warning.\n\"We are not able to see any good reason to do this are sure (y/n) ?\"\n\n> >>> and also mean (and that is the point) subsubmodule is a direct 'child' of both\n> >>> superproject and submodule.\n> >>\n> >> Which I think should not be possible. If that works with current\n> >> Git I suspect we have a bug to fix ... or does your other patch\n> >> make this work?\n> > \n> > You have no bug on this point without my modification this is not possible.\n> \n> Glad to hear that.\n> \n> >>> In this case where should the separate gitdir of subsubmodule be placed ?\n> >>>   - In superproject/modules/submodule/subsubmodule ?\n> >>>   - In superproject/submodule/modules/subsubmodule ?\n> >>>   - Depending on the 'git submodule update' command order ?\n> >>>   - Or both ?\n> >>\n> >> It should be placed in .git/modules/submodule/modules/subsubmodule\n> >> of the superproject (assuming the subsubmodule is part of the first\n> >> level submodule). But in your example that would live in\n> >> .git/modules/submodule/subsubmodule (but as mentioned above, I do\n> >> not consider this a valid setup because then two repositories would\n> >> be responsible for the data inside subsubmodule, which will lead to\n> >> lots of trouble).\n> > \n> > That is why a had proposed an option '--no-separate-git-dir'\n> > for 'git submodule <add|update>' then no repository is responsible for the data\n> > in subsubmodule except subsubmodule itself.\n> \n> As I mentioned in my other email, it doesn't matter at all for\n> the setup you're describing if the git directory lives under\n> .git/modules of the superproject or in a .git directory in the\n> submodule. The problem you're creating with your future patch\n> is related to the work tree, not the GIT_DIR: \"subsubmodule\"\n> could also be added to and tracked by \"submodule\" (as that is\n> completely unaware of \"subsubmodule\" already being tracked by\n> the superproject). Then you would end up in real trouble, as\n> \"superproject\" and \"submodule\" could have differing SHA-1s\n> recorded for subsubmodule. Don't go there, for just the same\n> reasons we do not allow that for files.\n> \n\nIn fact it mater.\nBecause multiples checkout of superproject and submodules in versions\nwhere subsubmodule is present and not.\nsubsubmodule could have been clone one time by submodule and one time\nby superproject.\nAnd then if they are cloned with --separate-gitdir subsubmodule can\nhave two gitdirs in superproject/modules/submodule/subsubmodule and\nin superproject/submodule/modules/subsubmodule.\nOnly one is active at a given time but they are two and not synchronized.\n\n> What is the use case you are trying to solve and why can that\n> not be handled by adding \"subsubmodule\" inside \"submodule\"?\n\nThe problem is access rights.\n\nImagine you have 2 people Pierre and Paul.\nEach with different access write on the server.\nPierre has full access on every things.\nPaul has full access on superproject and subsubmodule but no read/write\naccess to submodule only execution on the directory.\n\nI want all user to get every things they are allowed to have with the\ncommand 'git submodule update --init --recursive'.\nThen as Paul can not clone submodule he can not get subsubmodule\nrecursively through it. And I need superproject to add also\nsubmodule/subsubmodule.\n"},{"id":"236282","messageId":"531A4FA3.3040007@web.de","threadId":"36038","inReplyTo":"1394144428.7891.33.camel@Naugrim","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-03-07T23:00:51Z","receivedAt":"2014-03-07T23:00:51Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 06.03.2014 23:20, schrieb Henri GEIST:\n> Le jeudi 06 mars 2014 à 21:51 +0100, Jens Lehmann a écrit :\n>> Am 06.03.2014 21:15, schrieb Henri GEIST:\n>>> Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :\n>>>> Am 06.03.2014 02:25, schrieb Henri GEIST:\n>>>> Wow, that shouldn't even work (as everything inside \"submodule\"\n>>>> shouldn't be part of the superproject but must be contained in\n>>>> the submodule itself). Do the \"git submodule\" script and other\n>>>> git commands like \"git status\" work for you in such setups?\n>>>\n>>> As I stated above it is the purpose of the other patch that I have not already send\n>>> to implement this behavior. And that is why it work.\n>>\n>> Ok.\n>>\n>>> Everything including 'git submodule' and 'git status' work perfectly.\n>>> The intent of this patch is only to permit this for gitlinks. Not for regular files.\n>>\n>> But I still believe that this shouldn't be permitted at all,\n>> no matter if files or submodules are concerned. The pitfalls\n>> files face in such a scenario are pretty much the same for\n>> submodules too.\n> \n> May be you have a good argument for this belief ?\n\nSure, I stated it further down:\n\n>> The problem you're creating with your future patch\n>> is related to the work tree, not the GIT_DIR: \"subsubmodule\"\n>> could also be added to and tracked by \"submodule\" (as that is\n>> completely unaware of \"subsubmodule\" already being tracked by\n>> the superproject). Then you would end up in real trouble, as\n>> \"superproject\" and \"submodule\" could have differing SHA-1s\n>> recorded for subsubmodule. Don't go there, for just the same\n>> reasons we do not allow that for files.\n\n> As for the difference between submodules and regular files\n> the only difference is in the meaning.\n> Technically directory are just a special kind of file.\n> But there day to day use is drastically different of\n> the use of files which are not directories.\n> I am not against enabling it for files as well.\n> I am just unable to imagine a case where it make sens.\n\nIt doesn't make sense for both files and submodules.\n\n> A possible solution when someone try to do it is to issue a warning.\n> \"We are not able to see any good reason to do this are sure (y/n) ?\"\n\nNo, the only possible solution I see is not to allow that at\nall.\n\n>>>>> In this case where should the separate gitdir of subsubmodule be placed ?\n>>>>>   - In superproject/modules/submodule/subsubmodule ?\n>>>>>   - In superproject/submodule/modules/subsubmodule ?\n>>>>>   - Depending on the 'git submodule update' command order ?\n>>>>>   - Or both ?\n>>>>\n>>>> It should be placed in .git/modules/submodule/modules/subsubmodule\n>>>> of the superproject (assuming the subsubmodule is part of the first\n>>>> level submodule). But in your example that would live in\n>>>> .git/modules/submodule/subsubmodule (but as mentioned above, I do\n>>>> not consider this a valid setup because then two repositories would\n>>>> be responsible for the data inside subsubmodule, which will lead to\n>>>> lots of trouble).\n>>>\n>>> That is why a had proposed an option '--no-separate-git-dir'\n>>> for 'git submodule <add|update>' then no repository is responsible for the data\n>>> in subsubmodule except subsubmodule itself.\n>>\n>> As I mentioned in my other email, it doesn't matter at all for\n>> the setup you're describing if the git directory lives under\n>> .git/modules of the superproject or in a .git directory in the\n>> submodule. The problem you're creating with your future patch\n>> is related to the work tree, not the GIT_DIR: \"subsubmodule\"\n>> could also be added to and tracked by \"submodule\" (as that is\n>> completely unaware of \"subsubmodule\" already being tracked by\n>> the superproject). Then you would end up in real trouble, as\n>> \"superproject\" and \"submodule\" could have differing SHA-1s\n>> recorded for subsubmodule. Don't go there, for just the same\n>> reasons we do not allow that for files.\n> \n> In fact it mater.\n> Because multiples checkout of superproject and submodules in versions\n> where subsubmodule is present and not.\n> subsubmodule could have been clone one time by submodule and one time\n> by superproject.\n\nAnd each would have a different .git directory. Where is the\nproblem with that? Size? Different refs?\n\n> And then if they are cloned with --separate-gitdir subsubmodule can\n> have two gitdirs in superproject/modules/submodule/subsubmodule and\n> in superproject/submodule/modules/subsubmodule.\n> Only one is active at a given time but they are two and not synchronized.\n\nBut the synchronization is done via the superproject, no?\n\n>> What is the use case you are trying to solve and why can that\n>> not be handled by adding \"subsubmodule\" inside \"submodule\"?\n> \n> The problem is access rights.\n> \n> Imagine you have 2 people Pierre and Paul.\n> Each with different access write on the server.\n> Pierre has full access on every things.\n> Paul has full access on superproject and subsubmodule but no read/write\n> access to submodule only execution on the directory.\n\nOk, I think I'm slowly beginning to understand your setup.\n\n> I want all user to get every things they are allowed to have with the\n> command 'git submodule update --init --recursive'.\n> Then as Paul can not clone submodule he can not get subsubmodule\n> recursively through it.\n\nSure, that's how it should work. Paul could only work on a branch\nwhere \"submodule\" is an empty directory containing \"subsubmodule\",\nas he doesn't have the rights to clone \"submodule\".\n\n> And I need superproject to add also submodule/subsubmodule.\n\nNo. Never let the same file/directory be tracked by two git\nrepositories at the same time. Give Paul a branch to work on\nwhere \"submodule\" is just an empty directory, and everything\nwill be fine. Or move \"subsubmodule\" outside of \"submodule\"\n(and let a symbolic link point to the new location if the\npath cannot be easily changed). Would that work for you?\n"},{"id":"236362","messageId":"1394442486.7891.45.camel@Naugrim","threadId":"36038","inReplyTo":"531A4FA3.3040007@web.de","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Henri GEIST","fromEmail":"geist.henri@laposte.net","sentAt":"2014-03-10T09:08:06Z","receivedAt":"2014-03-10T09:08:06Z","isPatch":true,"sender":{"key":"geist.henri@laposte.net","avatar":"https://avatars.githubusercontent.com/u/42912271?v=4"},"body":"Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit :\n> Am 06.03.2014 23:20, schrieb Henri GEIST:\n> > Le jeudi 06 mars 2014 à 21:51 +0100, Jens Lehmann a écrit :\n> >> Am 06.03.2014 21:15, schrieb Henri GEIST:\n> >>> Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :\n> >>>> Am 06.03.2014 02:25, schrieb Henri GEIST:\n> >>>> Wow, that shouldn't even work (as everything inside \"submodule\"\n> >>>> shouldn't be part of the superproject but must be contained in\n> >>>> the submodule itself). Do the \"git submodule\" script and other\n> >>>> git commands like \"git status\" work for you in such setups?\n> >>>\n> >>> As I stated above it is the purpose of the other patch that I have not already send\n> >>> to implement this behavior. And that is why it work.\n> >>\n> >> Ok.\n> >>\n> >>> Everything including 'git submodule' and 'git status' work perfectly.\n> >>> The intent of this patch is only to permit this for gitlinks. Not for regular files.\n> >>\n> >> But I still believe that this shouldn't be permitted at all,\n> >> no matter if files or submodules are concerned. The pitfalls\n> >> files face in such a scenario are pretty much the same for\n> >> submodules too.\n> > \n> > May be you have a good argument for this belief ?\n> \n> Sure, I stated it further down:\n> \n> >> The problem you're creating with your future patch\n> >> is related to the work tree, not the GIT_DIR: \"subsubmodule\"\n> >> could also be added to and tracked by \"submodule\" (as that is\n> >> completely unaware of \"subsubmodule\" already being tracked by\n> >> the superproject). Then you would end up in real trouble, as\n> >> \"superproject\" and \"submodule\" could have differing SHA-1s\n> >> recorded for subsubmodule. Don't go there, for just the same\n> >> reasons we do not allow that for files.\n> \n> > As for the difference between submodules and regular files\n> > the only difference is in the meaning.\n> > Technically directory are just a special kind of file.\n> > But there day to day use is drastically different of\n> > the use of files which are not directories.\n> > I am not against enabling it for files as well.\n> > I am just unable to imagine a case where it make sens.\n> \n> It doesn't make sense for both files and submodules.\n> \n> > A possible solution when someone try to do it is to issue a warning.\n> > \"We are not able to see any good reason to do this are sure (y/n) ?\"\n> \n> No, the only possible solution I see is not to allow that at\n> all.\n> \n> >>>>> In this case where should the separate gitdir of subsubmodule be placed ?\n> >>>>>   - In superproject/modules/submodule/subsubmodule ?\n> >>>>>   - In superproject/submodule/modules/subsubmodule ?\n> >>>>>   - Depending on the 'git submodule update' command order ?\n> >>>>>   - Or both ?\n> >>>>\n> >>>> It should be placed in .git/modules/submodule/modules/subsubmodule\n> >>>> of the superproject (assuming the subsubmodule is part of the first\n> >>>> level submodule). But in your example that would live in\n> >>>> .git/modules/submodule/subsubmodule (but as mentioned above, I do\n> >>>> not consider this a valid setup because then two repositories would\n> >>>> be responsible for the data inside subsubmodule, which will lead to\n> >>>> lots of trouble).\n> >>>\n> >>> That is why a had proposed an option '--no-separate-git-dir'\n> >>> for 'git submodule <add|update>' then no repository is responsible for the data\n> >>> in subsubmodule except subsubmodule itself.\n> >>\n> >> As I mentioned in my other email, it doesn't matter at all for\n> >> the setup you're describing if the git directory lives under\n> >> .git/modules of the superproject or in a .git directory in the\n> >> submodule. The problem you're creating with your future patch\n> >> is related to the work tree, not the GIT_DIR: \"subsubmodule\"\n> >> could also be added to and tracked by \"submodule\" (as that is\n> >> completely unaware of \"subsubmodule\" already being tracked by\n> >> the superproject). Then you would end up in real trouble, as\n> >> \"superproject\" and \"submodule\" could have differing SHA-1s\n> >> recorded for subsubmodule. Don't go there, for just the same\n> >> reasons we do not allow that for files.\n> > \n> > In fact it mater.\n> > Because multiples checkout of superproject and submodules in versions\n> > where subsubmodule is present and not.\n> > subsubmodule could have been clone one time by submodule and one time\n> > by superproject.\n> \n> And each would have a different .git directory. Where is the\n> problem with that? Size? Different refs?\n>\n\nThe problem is having two gitdir for one worktree.\nwith the .git file in the worktree pointing sometime on one and sometime on\nthe other.\n \n> > And then if they are cloned with --separate-gitdir subsubmodule can\n> > have two gitdirs in superproject/modules/submodule/subsubmodule and\n> > in superproject/submodule/modules/subsubmodule.\n> > Only one is active at a given time but they are two and not synchronized.\n> \n> But the synchronization is done via the superproject, no?\n> \n\nOnly lot of careful manual command by the user could keep them synchronize.\nBut it is big wast of time. For no added value.\nIt is quicker to make subsubmodule a regular clone without a separate gitdir\nthen there is nothing needing a synchronization.\n\n> >> What is the use case you are trying to solve and why can that\n> >> not be handled by adding \"subsubmodule\" inside \"submodule\"?\n> > \n> > The problem is access rights.\n> > \n> > Imagine you have 2 people Pierre and Paul.\n> > Each with different access write on the server.\n> > Pierre has full access on every things.\n> > Paul has full access on superproject and subsubmodule but no read/write\n> > access to submodule only execution on the directory.\n> \n> Ok, I think I'm slowly beginning to understand your setup.\n> \n> > I want all user to get every things they are allowed to have with the\n> > command 'git submodule update --init --recursive'.\n> > Then as Paul can not clone submodule he can not get subsubmodule\n> > recursively through it.\n> \n> Sure, that's how it should work. Paul could only work on a branch\n> where \"submodule\" is an empty directory containing \"subsubmodule\",\n> as he doesn't have the rights to clone \"submodule\".\n\nI will not redundantly create a branch for each user on the server.\nWhen users clone the server it already create a special branch for them\n'master' which track 'origin/master'. And if each user have its own branch\non the server it will completely defeat the goal of the server \"collaboration\".\nAnd transform the git server in simple rsync server.\n\n> \n> > And I need superproject to add also submodule/subsubmodule.\n> \n> No. Never let the same file/directory be tracked by two git\n> repositories at the same time. Give Paul a branch to work on\n> where \"submodule\" is just an empty directory, and everything\n> will be fine. Or move \"subsubmodule\" outside of \"submodule\"\n> (and let a symbolic link point to the new location if the\n> path cannot be easily changed). Would that work for you?\n\nIf I use symbolic links it will just as gitlink enable to use the\nsame subsubmodule clone by more than one superproject but with two\nmajor problems :\n  - symbolic links do not work under Windows and some of my users do\n    not even know something else could exist.\n  - symbolic links will not store the SHA-1 of the subsubmodule.\n    And a 'git status' in the repository containing the symbolic link\n    will say nothing about subsubmodule state.\n\n\n\n\nI think where we diverge is in the way we are looking gitlinks.\nWhere you see a hierarchic tree, I see a web.\nAnd I use gitlinks just like multiplatform symbolic links storing\nthe SHA-1 of there destination and pointing exclusively on git repositories.\n\n\n"},{"id":"236456","messageId":"20140310203245.GB5345@sandbox-ub","threadId":"36038","inReplyTo":"1394442486.7891.45.camel@Naugrim","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2014-03-10T20:32:47Z","receivedAt":"2014-03-10T20:32:47Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Mar 10, 2014 at 10:08:06AM +0100, Henri GEIST wrote:\n> Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit :\n> > Am 06.03.2014 23:20, schrieb Henri GEIST:\n> > >> What is the use case you are trying to solve and why can that\n> > >> not be handled by adding \"subsubmodule\" inside \"submodule\"?\n> > > \n> > > The problem is access rights.\n> > > \n> > > Imagine you have 2 people Pierre and Paul.\n> > > Each with different access write on the server.\n> > > Pierre has full access on every things.\n> > > Paul has full access on superproject and subsubmodule but no read/write\n> > > access to submodule only execution on the directory.\n> > \n> > Ok, I think I'm slowly beginning to understand your setup.\n> > \n> > > I want all user to get every things they are allowed to have with the\n> > > command 'git submodule update --init --recursive'.\n> > > Then as Paul can not clone submodule he can not get subsubmodule\n> > > recursively through it.\n> > \n> > Sure, that's how it should work. Paul could only work on a branch\n> > where \"submodule\" is an empty directory containing \"subsubmodule\",\n> > as he doesn't have the rights to clone \"submodule\".\n> \n> I will not redundantly create a branch for each user on the server.\n> When users clone the server it already create a special branch for them\n> 'master' which track 'origin/master'. And if each user have its own branch\n> on the server it will completely defeat the goal of the server \"collaboration\".\n> And transform the git server in simple rsync server.\n\nI do not think that is what Jens was suggesting. It does not matter in\nwhich branch they work, they can directly use master if you like. What\nhe was suggesting is that they create their repository structure like\nthis:\n\ngit clone git@somewhere.net:superproject.git\ncd superproject/submodule\ngit clone git@somehwere.net:subsubmodule.git\ncd subsubmodule\n... work, commit, work, commit ...\n\nThe same applies for the superproject. Now only someone with access to\nthe submodule has to update the registered sha1 once the work is pushed\nto submodule.\n\n> > > And I need superproject to add also submodule/subsubmodule.\n> > \n> > No. Never let the same file/directory be tracked by two git\n> > repositories at the same time. Give Paul a branch to work on\n> > where \"submodule\" is just an empty directory, and everything\n> > will be fine. Or move \"subsubmodule\" outside of \"submodule\"\n> > (and let a symbolic link point to the new location if the\n> > path cannot be easily changed). Would that work for you?\n> \n> If I use symbolic links it will just as gitlink enable to use the\n> same subsubmodule clone by more than one superproject but with two\n> major problems :\n>   - symbolic links do not work under Windows and some of my users do\n>     not even know something else could exist.\n>   - symbolic links will not store the SHA-1 of the subsubmodule.\n>     And a 'git status' in the repository containing the symbolic link\n>     will say nothing about subsubmodule state.\n\nHere you are also missing something. What Jens was suggesting was that\nyou move your subsubmodule directly underneath the superproject and from\nthe old location you create a link to the new location for a quick\ntransition. But you can also change all paths in your project to point\nto the new location. But in the new location you will have subsubmodule\nregistered as a submodule only that it is now directly linked (as\nsubmodule) from the superproject instead of the submodule.\n\n> I think where we diverge is in the way we are looking gitlinks.\n> Where you see a hierarchic tree, I see a web.\n> And I use gitlinks just like multiplatform symbolic links storing\n> the SHA-1 of there destination and pointing exclusively on git repositories.\n\nWell but the problem with a web is that it will introduce a lot of\nproblems that need to be solved. Some repository has to have the\nauthority about a file (or link). If you have a file in multiple\nrepositories overlayed how do you know who is in charge and when?\n\nThere is a reason why it is designed like this: simplicity. I currently\ndo not see how your web idea can be simple without introducing a lot of\nuser interface questions.\n\nCheers Heiko\n"},{"id":"236489","messageId":"1394531703.7891.54.camel@Naugrim","threadId":"36038","inReplyTo":"20140310203245.GB5345@sandbox-ub","subject":"Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Henri GEIST","fromEmail":"geist.henri@laposte.net","sentAt":"2014-03-11T09:55:03Z","receivedAt":"2014-03-11T09:55:03Z","isPatch":true,"sender":{"key":"geist.henri@laposte.net","avatar":"https://avatars.githubusercontent.com/u/42912271?v=4"},"body":"Le lundi 10 mars 2014 à 21:32 +0100, Heiko Voigt a écrit :\n> On Mon, Mar 10, 2014 at 10:08:06AM +0100, Henri GEIST wrote:\n> > Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit :\n> > > Am 06.03.2014 23:20, schrieb Henri GEIST:\n> > > >> What is the use case you are trying to solve and why can that\n> > > >> not be handled by adding \"subsubmodule\" inside \"submodule\"?\n> > > > \n> > > > The problem is access rights.\n> > > > \n> > > > Imagine you have 2 people Pierre and Paul.\n> > > > Each with different access write on the server.\n> > > > Pierre has full access on every things.\n> > > > Paul has full access on superproject and subsubmodule but no read/write\n> > > > access to submodule only execution on the directory.\n> > > \n> > > Ok, I think I'm slowly beginning to understand your setup.\n> > > \n> > > > I want all user to get every things they are allowed to have with the\n> > > > command 'git submodule update --init --recursive'.\n> > > > Then as Paul can not clone submodule he can not get subsubmodule\n> > > > recursively through it.\n> > > \n> > > Sure, that's how it should work. Paul could only work on a branch\n> > > where \"submodule\" is an empty directory containing \"subsubmodule\",\n> > > as he doesn't have the rights to clone \"submodule\".\n> > \n> > I will not redundantly create a branch for each user on the server.\n> > When users clone the server it already create a special branch for them\n> > 'master' which track 'origin/master'. And if each user have its own branch\n> > on the server it will completely defeat the goal of the server \"collaboration\".\n> > And transform the git server in simple rsync server.\n> \n> I do not think that is what Jens was suggesting. It does not matter in\n> which branch they work, they can directly use master if you like. What\n> he was suggesting is that they create their repository structure like\n> this:\n> \n> git clone git@somewhere.net:superproject.git\n> cd superproject/submodule\n> git clone git@somehwere.net:subsubmodule.git\n> cd subsubmodule\n> ... work, commit, work, commit ...\n> \n> The same applies for the superproject. Now only someone with access to\n> the submodule has to update the registered sha1 once the work is pushed\n> to submodule.\n\nI am not sure to understand everything.\nBut if you suggest to clone manually subsubmodule because it could\nnot be clone recursively by submodule due to the lake of access write\nto get submodule.\n\nIt is not practical in my use cases.\nTwo of the superprojects I have in charge contains hundreds of submodules\nor subsubmodules and I have too much users with disparate computer skills.\n\nGetting all what a user has access on should be just a recursive clone.\n\n> \n> > > > And I need superproject to add also submodule/subsubmodule.\n> > > \n> > > No. Never let the same file/directory be tracked by two git\n> > > repositories at the same time. Give Paul a branch to work on\n> > > where \"submodule\" is just an empty directory, and everything\n> > > will be fine. Or move \"subsubmodule\" outside of \"submodule\"\n> > > (and let a symbolic link point to the new location if the\n> > > path cannot be easily changed). Would that work for you?\n> > \n> > If I use symbolic links it will just as gitlink enable to use the\n> > same subsubmodule clone by more than one superproject but with two\n> > major problems :\n> >   - symbolic links do not work under Windows and some of my users do\n> >     not even know something else could exist.\n> >   - symbolic links will not store the SHA-1 of the subsubmodule.\n> >     And a 'git status' in the repository containing the symbolic link\n> >     will say nothing about subsubmodule state.\n> \n> Here you are also missing something. What Jens was suggesting was that\n> you move your subsubmodule directly underneath the superproject and from\n> the old location you create a link to the new location for a quick\n> transition. But you can also change all paths in your project to point\n> to the new location. But in the new location you will have subsubmodule\n> registered as a submodule only that it is now directly linked (as\n> submodule) from the superproject instead of the submodule.\n> \n\nOk but in this case what happen to someone cloning only submodule but\nnot superproject ? He will not get subsubmodule which is part of it.\nJust a dead symbolic link with no hint on what is missing behind.\n\nEach of my submodules (at any level) should be usable superprojects by\nthem self having a gitlink to each subsubmodules they needs.\n\n> > I think where we diverge is in the way we are looking gitlinks.\n> > Where you see a hierarchic tree, I see a web.\n> > And I use gitlinks just like multiplatform symbolic links storing\n> > the SHA-1 of there destination and pointing exclusively on git repositories.\n> \n> Well but the problem with a web is that it will introduce a lot of\n> problems that need to be solved. Some repository has to have the\n> authority about a file (or link). If you have a file in multiple\n> repositories overlayed how do you know who is in charge and when?\n> \n\nIt will not introduce a lot of problems.\nMe and my teams are using gitlinks this way every days for 2 years know.\nWith a web far more complex than the example I give above.\nAnd the problem you are speaking about and which we solve with the\n--no-separate-git-dir option is the only one we encounter until now.\n\nThis solve the question of who is in charge ? and when ?\nsubsubmodule is in charge of itself. Always.\n\nI know there is some good reasons for the separate gitdir.\nBut none of them bother me in my day to day use.\nThat is why I came with this simple solution\n\nAnother solution to combine all advantages.\nIs deciding to always make superproject in charge and place a link\n$SUBMODULE_GIT_DIR/modules/link_to_subsubmodule_gitdir\npointing to $SUPERPROJECT_GIT_DIR/modules/submodule/subsubmodule.\n\nI think I can write a 3 step patch doing just that :\n\n  1) A little change in the $GIT_DIR/modules layout making the\n$SUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule/.git instead of\n$SUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule\n\nThen it will be possible to have\n$SUBSUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule/subsubmodule/.git\nand so on without risk of name collision in case subsubmodule have a name like\n'branches', 'hooks', 'refs' or anything like that.\n\n  2) Making submodules aware that they have been cloned has submodule and\nwhere is at least one of their superproject that is the non trivial part.\nMaybe choosing the one which actually clone it.\nAnother solution is to simply found it by the fact the $SUBMODULE_GIT_DIR\nis supposed to be in the $SUPERPROJECT_GIT_DIR.\n\n  3) Making 'git submodule <add|update>' search recursively through its\nsuperprojects or directly for the top one and place adequately its own\n$SUBSUBMODULE_GIT_DIR.\n\n\n> There is a reason why it is designed like this: simplicity. I currently\n> do not see how your web idea can be simple without introducing a lot of\n> user interface questions.\n> \n\nWorking with the web idea for several time now I can ensure you that\nGit is so well designed that it is ready to use with this concept.\nI have no user interface problem except the one we are speaking about.\n\n> Cheers Heiko\n\n\n"},{"id":"236529","messageId":"20140311201110.GB4833@sandbox-ub","threadId":"36038","inReplyTo":"1394531703.7891.54.camel@Naugrim","subject":"Re: Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2014-03-11T20:11:10Z","receivedAt":"2014-03-11T20:11:10Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Mar 11, 2014 at 10:55:03AM +0100, Henri GEIST wrote:\n> Le lundi 10 mars 2014 à 21:32 +0100, Heiko Voigt a écrit :\n> > On Mon, Mar 10, 2014 at 10:08:06AM +0100, Henri GEIST wrote:\n> > > Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit :\n> > > > Am 06.03.2014 23:20, schrieb Henri GEIST:\n> > > > >> What is the use case you are trying to solve and why can that\n> > > > >> not be handled by adding \"subsubmodule\" inside \"submodule\"?\n> > > > > \n> > > > > The problem is access rights.\n> > > > > \n> > > > > Imagine you have 2 people Pierre and Paul.\n> > > > > Each with different access write on the server.\n> > > > > Pierre has full access on every things.\n> > > > > Paul has full access on superproject and subsubmodule but no read/write\n> > > > > access to submodule only execution on the directory.\n> > > > \n> > > > Ok, I think I'm slowly beginning to understand your setup.\n> > > > \n> > > > > I want all user to get every things they are allowed to have with the\n> > > > > command 'git submodule update --init --recursive'.\n> > > > > Then as Paul can not clone submodule he can not get subsubmodule\n> > > > > recursively through it.\n> > > > \n> > > > Sure, that's how it should work. Paul could only work on a branch\n> > > > where \"submodule\" is an empty directory containing \"subsubmodule\",\n> > > > as he doesn't have the rights to clone \"submodule\".\n> > > \n> > > I will not redundantly create a branch for each user on the server.\n> > > When users clone the server it already create a special branch for them\n> > > 'master' which track 'origin/master'. And if each user have its own branch\n> > > on the server it will completely defeat the goal of the server \"collaboration\".\n> > > And transform the git server in simple rsync server.\n> > \n> > I do not think that is what Jens was suggesting. It does not matter in\n> > which branch they work, they can directly use master if you like. What\n> > he was suggesting is that they create their repository structure like\n> > this:\n> > \n> > git clone git@somewhere.net:superproject.git\n> > cd superproject/submodule\n> > git clone git@somehwere.net:subsubmodule.git\n> > cd subsubmodule\n> > ... work, commit, work, commit ...\n> > \n> > The same applies for the superproject. Now only someone with access to\n> > the submodule has to update the registered sha1 once the work is pushed\n> > to submodule.\n> \n> I am not sure to understand everything.\n> But if you suggest to clone manually subsubmodule because it could\n> not be clone recursively by submodule due to the lake of access write\n> to get submodule.\n> \n> It is not practical in my use cases.\n> Two of the superprojects I have in charge contains hundreds of submodules\n> or subsubmodules and I have too much users with disparate computer skills.\n> \n> Getting all what a user has access on should be just a recursive clone.\n\nThen I would think about getting rid of the recursion part as it seems\nyou have interdependencies which can only be solved by a package\nmanagement system. I would see the superproject as this package\nmanagement system, but it requires you to have all the submodules next\nto each other instead of contained in each other.\n\nI think in terms of combining libraries that is actually the correct\nsolution because there can be modules that need each other. Some\nsubmodule A might evolve and add a dependency to a subsubmodule B that\nis itself contained in another submodule C. Then it just does not feel\ncorrect anymore that B is contained in C. You want to have one instance\nthat is in charge of all the dependencies, that is IMO directly the\nsuperproject and not something that reaches through another submodule\nto record a dependency to a subsubmodule.\n\n> > > > > And I need superproject to add also submodule/subsubmodule.\n> > > > \n> > > > No. Never let the same file/directory be tracked by two git\n> > > > repositories at the same time. Give Paul a branch to work on\n> > > > where \"submodule\" is just an empty directory, and everything\n> > > > will be fine. Or move \"subsubmodule\" outside of \"submodule\"\n> > > > (and let a symbolic link point to the new location if the\n> > > > path cannot be easily changed). Would that work for you?\n> > > \n> > > If I use symbolic links it will just as gitlink enable to use the\n> > > same subsubmodule clone by more than one superproject but with two\n> > > major problems :\n> > >   - symbolic links do not work under Windows and some of my users do\n> > >     not even know something else could exist.\n> > >   - symbolic links will not store the SHA-1 of the subsubmodule.\n> > >     And a 'git status' in the repository containing the symbolic link\n> > >     will say nothing about subsubmodule state.\n> > \n> > Here you are also missing something. What Jens was suggesting was that\n> > you move your subsubmodule directly underneath the superproject and from\n> > the old location you create a link to the new location for a quick\n> > transition. But you can also change all paths in your project to point\n> > to the new location. But in the new location you will have subsubmodule\n> > registered as a submodule only that it is now directly linked (as\n> > submodule) from the superproject instead of the submodule.\n> > \n> \n> Ok but in this case what happen to someone cloning only submodule but\n> not superproject ? He will not get subsubmodule which is part of it.\n> Just a dead symbolic link with no hint on what is missing behind.\n> \n> Each of my submodules (at any level) should be usable superprojects by\n> them self having a gitlink to each subsubmodules they needs.\n\nThen you will end up duplicating many submodules if everything should\ncontain everything it needs. Think about the example I described above.\nIn case of libraries, that will become a management nightmare.\n\n> > > I think where we diverge is in the way we are looking gitlinks.\n> > > Where you see a hierarchic tree, I see a web.\n> > > And I use gitlinks just like multiplatform symbolic links storing\n> > > the SHA-1 of there destination and pointing exclusively on git repositories.\n> > \n> > Well but the problem with a web is that it will introduce a lot of\n> > problems that need to be solved. Some repository has to have the\n> > authority about a file (or link). If you have a file in multiple\n> > repositories overlayed how do you know who is in charge and when?\n> > \n> \n> It will not introduce a lot of problems.\n> Me and my teams are using gitlinks this way every days for 2 years know.\n> With a web far more complex than the example I give above.\n> And the problem you are speaking about and which we solve with the\n> --no-separate-git-dir option is the only one we encounter until now.\n> \n> This solve the question of who is in charge ? and when ?\n> subsubmodule is in charge of itself. Always.\n> \n> I know there is some good reasons for the separate gitdir.\n> But none of them bother me in my day to day use.\n> That is why I came with this simple solution\n> \n> Another solution to combine all advantages.\n> Is deciding to always make superproject in charge and place a link\n> $SUBMODULE_GIT_DIR/modules/link_to_subsubmodule_gitdir\n> pointing to $SUPERPROJECT_GIT_DIR/modules/submodule/subsubmodule.\n> \n> I think I can write a 3 step patch doing just that :\n> \n>   1) A little change in the $GIT_DIR/modules layout making the\n> $SUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule/.git instead of\n> $SUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule\n> \n> Then it will be possible to have\n> $SUBSUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule/subsubmodule/.git\n> and so on without risk of name collision in case subsubmodule have a name like\n> 'branches', 'hooks', 'refs' or anything like that.\n> \n>   2) Making submodules aware that they have been cloned has submodule and\n> where is at least one of their superproject that is the non trivial part.\n> Maybe choosing the one which actually clone it.\n> Another solution is to simply found it by the fact the $SUBMODULE_GIT_DIR\n> is supposed to be in the $SUPERPROJECT_GIT_DIR.\n> \n>   3) Making 'git submodule <add|update>' search recursively through its\n> superprojects or directly for the top one and place adequately its own\n> $SUBSUBMODULE_GIT_DIR.\n> \n> \n> > There is a reason why it is designed like this: simplicity. I currently\n> > do not see how your web idea can be simple without introducing a lot of\n> > user interface questions.\n> > \n> \n> Working with the web idea for several time now I can ensure you that\n> Git is so well designed that it is ready to use with this concept.\n> I have no user interface problem except the one we are speaking about.\n\nIf you have multiple superprojects for a submodule in which superproject\ndo you commit a change on a gitlink?\n\nDon't you end up having a lot of commits if you have to commit in\nmultiple superprojects?\n\nSuppose you have a directory layout like this:\n\nsuper\\\n   submoduleA\\\n   \tsubmoduleB\n\nWhat happens if submoduleA has no knowledge about submoduleB but super\ndecides to track it? Then on one point submoduleA decides to put files\ninto the directory named 'submoduleB'. What happens?\n\nJust a few questions that immediately pop into my mind.\n\nCheers Heiko\n"},{"id":"236545","messageId":"1394575671.7891.65.camel@Naugrim","threadId":"36038","inReplyTo":"20140311201110.GB4833@sandbox-ub","subject":"Re: Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.","fromName":"Henri GEIST","fromEmail":"geist.henri@laposte.net","sentAt":"2014-03-11T22:07:51Z","receivedAt":"2014-03-11T22:07:51Z","isPatch":true,"sender":{"key":"geist.henri@laposte.net","avatar":"https://avatars.githubusercontent.com/u/42912271?v=4"},"body":"Le mardi 11 mars 2014 à 21:11 +0100, Heiko Voigt a écrit :\n> On Tue, Mar 11, 2014 at 10:55:03AM +0100, Henri GEIST wrote:\n> > Le lundi 10 mars 2014 à 21:32 +0100, Heiko Voigt a écrit :\n> > > On Mon, Mar 10, 2014 at 10:08:06AM +0100, Henri GEIST wrote:\n> > > > Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit :\n> > > > > Am 06.03.2014 23:20, schrieb Henri GEIST:\n> > > > > >> What is the use case you are trying to solve and why can that\n> > > > > >> not be handled by adding \"subsubmodule\" inside \"submodule\"?\n> > > > > > \n> > > > > > The problem is access rights.\n> > > > > > \n> > > > > > Imagine you have 2 people Pierre and Paul.\n> > > > > > Each with different access write on the server.\n> > > > > > Pierre has full access on every things.\n> > > > > > Paul has full access on superproject and subsubmodule but no read/write\n> > > > > > access to submodule only execution on the directory.\n> > > > > \n> > > > > Ok, I think I'm slowly beginning to understand your setup.\n> > > > > \n> > > > > > I want all user to get every things they are allowed to have with the\n> > > > > > command 'git submodule update --init --recursive'.\n> > > > > > Then as Paul can not clone submodule he can not get subsubmodule\n> > > > > > recursively through it.\n> > > > > \n> > > > > Sure, that's how it should work. Paul could only work on a branch\n> > > > > where \"submodule\" is an empty directory containing \"subsubmodule\",\n> > > > > as he doesn't have the rights to clone \"submodule\".\n> > > > \n> > > > I will not redundantly create a branch for each user on the server.\n> > > > When users clone the server it already create a special branch for them\n> > > > 'master' which track 'origin/master'. And if each user have its own branch\n> > > > on the server it will completely defeat the goal of the server \"collaboration\".\n> > > > And transform the git server in simple rsync server.\n> > > \n> > > I do not think that is what Jens was suggesting. It does not matter in\n> > > which branch they work, they can directly use master if you like. What\n> > > he was suggesting is that they create their repository structure like\n> > > this:\n> > > \n> > > git clone git@somewhere.net:superproject.git\n> > > cd superproject/submodule\n> > > git clone git@somehwere.net:subsubmodule.git\n> > > cd subsubmodule\n> > > ... work, commit, work, commit ...\n> > > \n> > > The same applies for the superproject. Now only someone with access to\n> > > the submodule has to update the registered sha1 once the work is pushed\n> > > to submodule.\n> > \n> > I am not sure to understand everything.\n> > But if you suggest to clone manually subsubmodule because it could\n> > not be clone recursively by submodule due to the lake of access write\n> > to get submodule.\n> > \n> > It is not practical in my use cases.\n> > Two of the superprojects I have in charge contains hundreds of submodules\n> > or subsubmodules and I have too much users with disparate computer skills.\n> > \n> > Getting all what a user has access on should be just a recursive clone.\n> \n> Then I would think about getting rid of the recursion part as it seems\n> you have interdependencies which can only be solved by a package\n> management system. I would see the superproject as this package\n> management system, but it requires you to have all the submodules next\n> to each other instead of contained in each other.\n>\n\nYou put the finger on a key point.\n\nI use the submodule system exactly as a package management system.\nIt is even the only use I have of it. I am not able to imagine another use.\n(My imagination is limited).\nI really use 'git clone --recursive' as 'apt-get install'.\nAnd I am pretty sure you also.\n\nAnd in fact for the case where the submodules/packages should be side by\nside, I have a third patch witch enable just this by enabling '../' to be\npart of a gitlink.\nMuch of my submodules/packages make use of this feature but I also have the\ncase where the dependency make them contained in each others.\n \n> I think in terms of combining libraries that is actually the correct\n> solution because there can be modules that need each other. Some\n> submodule A might evolve and add a dependency to a subsubmodule B that\n> is itself contained in another submodule C. Then it just does not feel\n> correct anymore that B is contained in C. You want to have one instance\n> that is in charge of all the dependencies, that is IMO directly the\n> superproject and not something that reaches through another submodule\n> to record a dependency to a subsubmodule.\n\nRight.\nBut each module need to know by its own gitlinks which are its\ndependency to be able to track version compatibility and not rely on\nan hypothetic superproject which may or may not do it as a submodule\ndo not even know if it is part of a superproject.\nAnd could be include in totally different superprojects.\n\n> \n> > > > > > And I need superproject to add also submodule/subsubmodule.\n> > > > > \n> > > > > No. Never let the same file/directory be tracked by two git\n> > > > > repositories at the same time. Give Paul a branch to work on\n> > > > > where \"submodule\" is just an empty directory, and everything\n> > > > > will be fine. Or move \"subsubmodule\" outside of \"submodule\"\n> > > > > (and let a symbolic link point to the new location if the\n> > > > > path cannot be easily changed). Would that work for you?\n> > > > \n> > > > If I use symbolic links it will just as gitlink enable to use the\n> > > > same subsubmodule clone by more than one superproject but with two\n> > > > major problems :\n> > > >   - symbolic links do not work under Windows and some of my users do\n> > > >     not even know something else could exist.\n> > > >   - symbolic links will not store the SHA-1 of the subsubmodule.\n> > > >     And a 'git status' in the repository containing the symbolic link\n> > > >     will say nothing about subsubmodule state.\n> > > \n> > > Here you are also missing something. What Jens was suggesting was that\n> > > you move your subsubmodule directly underneath the superproject and from\n> > > the old location you create a link to the new location for a quick\n> > > transition. But you can also change all paths in your project to point\n> > > to the new location. But in the new location you will have subsubmodule\n> > > registered as a submodule only that it is now directly linked (as\n> > > submodule) from the superproject instead of the submodule.\n> > > \n> > \n> > Ok but in this case what happen to someone cloning only submodule but\n> > not superproject ? He will not get subsubmodule which is part of it.\n> > Just a dead symbolic link with no hint on what is missing behind.\n> > \n> > Each of my submodules (at any level) should be usable superprojects by\n> > them self having a gitlink to each subsubmodules they needs.\n> \n> Then you will end up duplicating many submodules if everything should\n> contain everything it needs. Think about the example I described above.\n> In case of libraries, that will become a management nightmare.\n> \n\nAs stated above in this case my other patch enable me to put the submodules\nsides by sides and address this issue. Then I have no duplication.\n\n> > > > I think where we diverge is in the way we are looking gitlinks.\n> > > > Where you see a hierarchic tree, I see a web.\n> > > > And I use gitlinks just like multiplatform symbolic links storing\n> > > > the SHA-1 of there destination and pointing exclusively on git repositories.\n> > > \n> > > Well but the problem with a web is that it will introduce a lot of\n> > > problems that need to be solved. Some repository has to have the\n> > > authority about a file (or link). If you have a file in multiple\n> > > repositories overlayed how do you know who is in charge and when?\n> > > \n> > \n> > It will not introduce a lot of problems.\n> > Me and my teams are using gitlinks this way every days for 2 years know.\n> > With a web far more complex than the example I give above.\n> > And the problem you are speaking about and which we solve with the\n> > --no-separate-git-dir option is the only one we encounter until now.\n> > \n> > This solve the question of who is in charge ? and when ?\n> > subsubmodule is in charge of itself. Always.\n> > \n> > I know there is some good reasons for the separate gitdir.\n> > But none of them bother me in my day to day use.\n> > That is why I came with this simple solution\n> > \n> > Another solution to combine all advantages.\n> > Is deciding to always make superproject in charge and place a link\n> > $SUBMODULE_GIT_DIR/modules/link_to_subsubmodule_gitdir\n> > pointing to $SUPERPROJECT_GIT_DIR/modules/submodule/subsubmodule.\n> > \n> > I think I can write a 3 step patch doing just that :\n> > \n> >   1) A little change in the $GIT_DIR/modules layout making the\n> > $SUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule/.git instead of\n> > $SUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule\n> > \n> > Then it will be possible to have\n> > $SUBSUBMODULE_GIT_DIR=$SUPERPROJECT_GIT_DIR/modules/submodule/subsubmodule/.git\n> > and so on without risk of name collision in case subsubmodule have a name like\n> > 'branches', 'hooks', 'refs' or anything like that.\n> > \n> >   2) Making submodules aware that they have been cloned has submodule and\n> > where is at least one of their superproject that is the non trivial part.\n> > Maybe choosing the one which actually clone it.\n> > Another solution is to simply found it by the fact the $SUBMODULE_GIT_DIR\n> > is supposed to be in the $SUPERPROJECT_GIT_DIR.\n> > \n> >   3) Making 'git submodule <add|update>' search recursively through its\n> > superprojects or directly for the top one and place adequately its own\n> > $SUBSUBMODULE_GIT_DIR.\n> > \n> > \n> > > There is a reason why it is designed like this: simplicity. I currently\n> > > do not see how your web idea can be simple without introducing a lot of\n> > > user interface questions.\n> > > \n> > \n> > Working with the web idea for several time now I can ensure you that\n> > Git is so well designed that it is ready to use with this concept.\n> > I have no user interface problem except the one we are speaking about.\n> \n> If you have multiple superprojects for a submodule in which superproject\n> do you commit a change on a gitlink?\n\nEach superproject impacted by the changes.\nBut only when I need it to be updated.\n\n> \n> Don't you end up having a lot of commits if you have to commit in\n> multiple superprojects?\n> \n\nI have only commit in project which have a real change which conceptually\nneed a commit.\nA careful design of projects modularization and dependency will not\nlead to unneeded commits. But if you create unneeded dependency between\nyour submodules you can have a lot of meaningless commit.\nIt is only a project design problem not a Git problem.\n\nBut in counterpart it add some capital value (at least to my eyes),\ntraceability of the dependency between submodules/packages through their SHA-1.\n\n> Suppose you have a directory layout like this:\n> \n> super\\\n>    submoduleA\\\n>    \tsubmoduleB\n> \n> What happens if submoduleA has no knowledge about submoduleB but super\n> decides to track it? Then on one point submoduleA decides to put files\n> into the directory named 'submoduleB'. What happens?\n> \n\nIt is a general design question not a Git question.\nIf super have put a submoduleB in the submoduleA directory it is intentional\nand should be sound in your design.\nAnd as designer I see no good reason to place submoduleB in a submoduleA already containing\na submoduleA directory or track file in submoduleB by submoduleA.\nAnd in fact Git prevent this.\nMy patch only enable it for gitlinks.\n\nBut maybe you have in mind a case where the maintainer of super will do this\nfor a good reason in this case I can enable it.\n\n> Just a few questions that immediately pop into my mind.\n> \n> Cheers Heiko\n\n\n"}]}