{"thread":{"id":"28070","subject":"[PATCH 0/2] Add an update=none option for 'loose' submodules","startedAt":"2011-08-11T17:51:44Z","lastAt":"2011-08-26T16:14:49Z","messageCount":15,"participants":["Heiko Voigt","Junio C Hamano","Jens Lehmann"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"173285","messageId":"cover.1312923673.git.hvoigt@hvoigt.net","threadId":"28070","inReplyTo":null,"subject":"[PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-11T17:51:44Z","receivedAt":"2011-08-11T17:51:44Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"If a submodule is used to seperate some bigger parts of a project into\nan optional directory it is helpful to not clone/update them by default.\n\nThis series implements a new value 'none' for submodule..update.\nIf this option is set a submodule will not be updated or cloned by\ndefault. If the user wants to work with the submodule he either needs\nto explicitely configure the update option to 'checkout' or pass\n--checkout as an option to the submodules. I chose this name to be\nconsistent with the existing --merge/--rebase options.\n\nWe have been talking about loose submodules for some time:\n\nRFC patch for this series\nhttp://thread.gmane.org/gmane.comp.version-control.git/175165\n\nUsing submodule groups/dependencies:\nhttp://thread.gmane.org/gmane.comp.version-control.git/130928/focus=131050\nhttp://thread.gmane.org/gmane.comp.version-control.git/176347/focus=178614\n\nThis lays the foundations for grouping of submodules. Once submodule\ngrouping will be implemented the value of submodule.$name.update\nprovides the default value when the user specifies no group. A group\nspecification could then be a layer on top which provides a shortcut to\nchoose other submodule.$name.update values to be registered in\n.git/config.\n\nHeiko Voigt (2):\n submodule: move update configuration variable further up\n add update 'none' flag to disable update of submodule by default\n\n Documentation/git-submodule.txt | 8 ++++-\n git-submodule.sh | 22 ++++++++++----\n t/t7406-submodule-update.sh | 62 +++++++++++++++++++++++++++++++++++++++\n 3 files changed, 85 insertions(+), 7 deletions(-)\n\n-- \n1.7.6.435.g741d34\n"},{"id":"173286","messageId":"5dcb346470d84b03276ec1d3693ab21a48681952.1312923673.git.hvoigt@hvoigt.net","threadId":"28070","inReplyTo":"cover.1312923673.git.hvoigt@hvoigt.net","subject":"[PATCH 1/2] submodule: move update configuration variable further up","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-11T17:51:45Z","receivedAt":"2011-08-11T17:51:45Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Lets always initialize the 'update_module' variable with the final\nvalue. This way we allow code which wants to check this configuration\nearly to do so right in the beginning of cmd_update().\n\nSigned-off-by: Heiko Voigt \n---\n git-submodule.sh | 13 +++++++------\n 1 files changed, 7 insertions(+), 6 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex f46862f..e544dbc 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -461,7 +461,13 @@ cmd_update()\n \t\tfi\n \t\tname=$(module_name \"$path\") || exit\n \t\turl=$(git config submodule.\"$name\".url)\n-\t\tupdate_module=$(git config submodule.\"$name\".update)\n+\t\tif ! test -z \"$update\"\n+\t\tthen\n+\t\t\tupdate_module=$update\n+\t\telse\n+\t\t\tupdate_module=$(git config submodule.\"$name\".update)\n+\t\tfi\n+\n \t\tif test -z \"$url\"\n \t\tthen\n \t\t\t# Only mention uninitialized submodules when its\n@@ -483,11 +489,6 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\tdie \"$(eval_gettext \"Unable to find current revision in submodule path '\\$path'\")\"\n \t\tfi\n \n-\t\tif ! test -z \"$update\"\n-\t\tthen\n-\t\t\tupdate_module=$update\n-\t\tfi\n-\n \t\tif test \"$subsha1\" != \"$sha1\"\n \t\tthen\n \t\t\tsubforce=$force\n-- \n1.7.6.435.g741d34\n"},{"id":"173287","messageId":"a8cbba7af22649f8cebaf56895304e9ae4378d75.1312923673.git.hvoigt@hvoigt.net","threadId":"28070","inReplyTo":"cover.1312923673.git.hvoigt@hvoigt.net","subject":"[PATCH 2/2] add update 'none' flag to disable update of submodule by default","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-11T17:51:46Z","receivedAt":"2011-08-11T17:51:46Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"This is useful to mark a submodule as unneeded by default. When this\noption is set and the user wants to work with such a submodule he\nneeds to configure 'submodule..update=checkout' or pass the\n--checkout option. Then the submodule can be handled like a normal\nsubmodule.\n\nSigned-off-by: Heiko Voigt \n---\n Documentation/git-submodule.txt | 8 ++++-\n git-submodule.sh | 9 +++++\n t/t7406-submodule-update.sh | 62 +++++++++++++++++++++++++++++++++++++++\n 3 files changed, 78 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 67cf5f0..6ec3fef 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -120,6 +120,8 @@ too (and can also report changes to a submodule's work tree).\n init::\n \tInitialize the submodules, i.e. register each submodule name\n \tand url found in .gitmodules into .git/config.\n+\tIt will also copy the value of `submodule.$name.update` into\n+\t.git/config.\n \tThe key used in .git/config is `submodule.$name.url`.\n \tThis command does not alter existing information in .git/config.\n \tYou can then customize the submodule clone URLs in .git/config\n@@ -133,7 +135,7 @@ update::\n \tcheckout the commit specified in the index of the containing repository.\n \tThis will make the submodules HEAD be detached unless `--rebase` or\n \t`--merge` is specified or the key `submodule.$name.update` is set to\n-\t`rebase` or `merge`.\n+\t`rebase`, `merge` or `none`.\n +\n 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@@ -141,6 +143,10 @@ submodule with the `--init` option.\n +\n If `--recursive` is specified, this command will recurse into the\n registered submodules, and update any nested submodules within.\n++\n+If the configuration key `submodule.$name.update` is set to `none` the\n+submodule with name `$name` will not be updated by default. This can be\n+overriden by adding `--checkout` to the command.\n \n summary::\n \tShow commit summary between the given commit (defaults to HEAD) and\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex e544dbc..34d2be6 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -429,6 +429,9 @@ cmd_update()\n \t\t--recursive)\n \t\t\trecursive=1\n \t\t\t;;\n+\t\t--checkout)\n+\t\t\tupdate=\"checkout\"\n+\t\t\t;;\n \t\t--)\n \t\t\tshift\n \t\t\tbreak\n@@ -468,6 +471,12 @@ cmd_update()\n \t\t\tupdate_module=$(git config submodule.\"$name\".update)\n \t\tfi\n \n+\t\tif test \"$update_module\" = \"none\"\n+\t\tthen\n+\t\t\techo \"Skipping submodule '$path'\"\n+\t\t\tcontinue\n+\t\tfi\n+\n \t\tif test -z \"$url\"\n \t\tthen\n \t\t\t# Only mention uninitialized submodules when its\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex c679f36..58877d3 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -30,6 +30,7 @@ test_expect_success 'setup a submodule tree' '\n \tgit clone super submodule &&\n \tgit clone super rebasing &&\n \tgit clone super merging &&\n+\tgit clone super none &&\n \t(cd super &&\n \t git submodule add ../submodule submodule &&\n \t test_tick &&\n@@ -58,6 +59,11 @@ test_expect_success 'setup a submodule tree' '\n \t test_tick &&\n \t git commit -m \"rebasing\"\n \t)\n+\t(cd super &&\n+\t git submodule add ../none none &&\n+\t test_tick &&\n+\t git commit -m \"none\"\n+\t)\n '\n \n test_expect_success 'submodule update detaching the HEAD ' '\n@@ -298,6 +304,62 @@ test_expect_success 'submodule update ignores update=rebase config for new submo\n \t)\n '\n \n+test_expect_success 'submodule init picks up update=none' '\n+\t(cd super &&\n+\t git config -f .gitmodules submodule.none.update none &&\n+\t git submodule init none &&\n+\t test \"none\" = \"$(git config submodule.none.update)\"\n+\t)\n+'\n+\n+test_expect_success 'submodule update - update=none in .git/config' '\n+\t(cd super &&\n+\t git config submodule.submodule.update none &&\n+\t (cd submodule &&\n+\t git checkout master &&\n+\t compare_head\n+\t ) &&\n+\t git diff --raw | grep \"\tsubmodule\" &&\n+\t git submodule update &&\n+\t git diff --raw | grep \"\tsubmodule\" &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git config --unset submodule.submodule.update &&\n+\t git submodule update submodule\n+\t)\n+'\n+\n+test_expect_success 'submodule update - update=none in .git/config but --checkout given' '\n+\t(cd super &&\n+\t git config submodule.submodule.update none &&\n+\t (cd submodule &&\n+\t git checkout master &&\n+\t compare_head\n+\t ) &&\n+\t git diff --raw | grep \"\tsubmodule\" &&\n+\t git submodule update --checkout &&\n+\t test_must_fail git diff --raw \\| grep \"\tsubmodule\" &&\n+\t (cd submodule &&\n+\t test_must_fail compare_head\n+\t ) &&\n+\t git config --unset submodule.submodule.update\n+\t)\n+'\n+\n+test_expect_success 'submodule update --init skips submodule with update=none' '\n+\t(cd super &&\n+\t git add .gitmodules &&\n+\t git commit -m \".gitmodules\"\n+\t) &&\n+\tgit clone super cloned &&\n+\t(cd cloned &&\n+\t git submodule update --init &&\n+\t test -e submodule/.git &&\n+\t test_must_fail test -e none/.git\n+\t)\n+'\n+\n test_expect_success 'submodule update continues after checkout error' '\n \t(cd super &&\n \t git reset --hard HEAD &&\n-- \n1.7.6.435.g741d34\n"},{"id":"173300","messageId":"7v8vqzreeo.fsf@alter.siamese.dyndns.org","threadId":"28070","inReplyTo":"cover.1312923673.git.hvoigt@hvoigt.net","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-11T18:28:31Z","receivedAt":"2011-08-11T18:28:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> If a submodule is used to seperate some bigger parts of a project into\n> an optional directory it is helpful to not clone/update them by default.\n\nSorry if I am slow, but I do not get this.\n\nI thought unless you say \"submodule init\" once, a submodule you are not\ninterested in should not be cloned nor updated at all. If that is not the\ncase, isn't it a bug to be fixed without a new configuration variable that\nfixes it only when it is set?\n\n> We have been talking about loose submodules for some time:\n\nAlso before introducing a new terminology \"loose submodule\", please define\nit somewhere. It feels confusing to me that a normal submodule, which\nshouldn't be auto-cloned nor auto-updated without \"submodule init\", needs\nto be called by a name other than simply a \"submodule\" but with an\nadjuctive \"loose submodule\".\n"},{"id":"173312","messageId":"20110811195955.GA21185@book.hvoigt.net","threadId":"28070","inReplyTo":"7v8vqzreeo.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-11T20:00:21Z","receivedAt":"2011-08-11T20:00:21Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi Junio,\n\nOn Thu, Aug 11, 2011 at 11:28:31AM -0700, Junio C Hamano wrote:\n> Heiko Voigt writes:\n> \n> > If a submodule is used to seperate some bigger parts of a project into\n> > an optional directory it is helpful to not clone/update them by default.\n> \n> Sorry if I am slow, but I do not get this.\n> \n> I thought unless you say \"submodule init\" once, a submodule you are not\n> interested in should not be cloned nor updated at all. If that is not the\n> case, isn't it a bug to be fixed without a new configuration variable that\n> fixes it only when it is set?\n\nWhat I usually do is say \"submodule init\" without any extra option once.\nThat will register all submodules from .gitmodules in the config. Now\nwhen I say \"submodule update\" all submodules would be cloned. In the\ncase of recursive submodules actually\n\n\tgit submodule update --init --recursive\n\nis the only command which can get you really everything in one go.\n\nDo you think the \"submodule init\" behavior is wrong? If so I think its a\nbit late to change this since people using submodules (me included)\nalready have got used to it.\n\nWith this config variable all submodules will still be registered to\n.git/config on \"submodule init\" but \"submodule update\" will skip those\nsubmodules. Since we already have merge and rebase as alternate options\nto update a submodule it just sounds logical to me to have an additional\noption to disable updating.\n\n> > We have been talking about loose submodules for some time:\n> \n> Also before introducing a new terminology \"loose submodule\", please define\n> it somewhere. It feels confusing to me that a normal submodule, which\n> shouldn't be auto-cloned nor auto-updated without \"submodule init\", needs\n> to be called by a name other than simply a \"submodule\" but with an\n> adjuctive \"loose submodule\".\n\nThats why I avoided talking about it in the docs. For the commit message\nI thought it would be kind of intuitive but I can update the commit\nmessage so that it becomes more clear.\n\nCheers Heiko\n"},{"id":"173553","messageId":"7vy5yujtr2.fsf@alter.siamese.dyndns.org","threadId":"28070","inReplyTo":"20110811195955.GA21185@book.hvoigt.net","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-15T20:37:53Z","receivedAt":"2011-08-15T20:37:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> On Thu, Aug 11, 2011 at 11:28:31AM -0700, Junio C Hamano wrote:\n>> Heiko Voigt writes:\n>> \n>> > If a submodule is used to seperate some bigger parts of a project into\n>> > an optional directory it is helpful to not clone/update them by default.\n>> \n>> Sorry if I am slow, but I do not get this.\n>> \n>> I thought unless you say \"submodule init\" once, a submodule you are not\n>> interested in should not be cloned nor updated at all. If that is not the\n>> case, isn't it a bug to be fixed without a new configuration variable that\n>> fixes it only when it is set?\n>\n> What I usually do is say \"submodule init\" without any extra option once.\n> That will register all submodules from .gitmodules in the config. Now\n> when I say \"submodule update\" all submodules would be cloned. In the\n> case of recursive submodules actually\n>\n> \tgit submodule update --init --recursive\n>\n> is the only command which can get you really everything in one go.\n>\n> Do you think the \"submodule init\" behavior is wrong? If so I think its a\n> bit late to change this since people using submodules (me included)\n> already have got used to it.\n>\n> With this config variable all submodules will still be registered to\n> .git/config on \"submodule init\" but \"submodule update\" will skip those\n> submodules.\n\nOk, that sort-of makes sense, but we have been using \"do we have the\nsubmodule registered in the .git/config of the superproject?\" to decide\n\"does the user interested in having a checkout of the submodule?\" (I think\nin the ancient days it was \"do we have .git in that submodule directory?\"\nthat decided it, but we dropped that because it won't work when switching\nbranches that has and does not have the submodule in superproject).\n\nIt is somewhat worrying that some parts of the system may still be using\nthat old criteria \"do we have it in .git/config of the superproject?\" to\ndecide if the user is interested in the submodule. If so they need to be\nupdated to take this new semantics \"do we have it in .git/config without\nits submodule.$name.update set to none\" into account. We would probably\nneed to have a paragraph in the release notes to warn about the semantics\nchange (which I tend to agree with you that it is a good one).\n\n>> > We have been talking about loose submodules for some time:\n>> \n>> Also before introducing a new terminology \"loose submodule\", please define\n>> it somewhere. It feels confusing to me that a normal submodule, which\n>> shouldn't be auto-cloned nor auto-updated without \"submodule init\", needs\n>> to be called by a name other than simply a \"submodule\" but with an\n>> adjuctive \"loose submodule\".\n>\n> Thats why I avoided talking about it in the docs. For the commit message\n> I thought it would be kind of intuitive but I can update the commit\n> message so that it becomes more clear.\n\nThat sounds like a good thing to do.\n\nThanks.\n"},{"id":"174039","messageId":"20110822200052.GC11745@sandbox-rc","threadId":"28070","inReplyTo":"7vy5yujtr2.fsf@alter.siamese.dyndns.org","subject":"Re: Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-22T20:00:52Z","receivedAt":"2011-08-22T20:00:52Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Mon, Aug 15, 2011 at 01:37:53PM -0700, Junio C Hamano wrote:\n> Heiko Voigt writes:\n> \n> > On Thu, Aug 11, 2011 at 11:28:31AM -0700, Junio C Hamano wrote:\n> >> Heiko Voigt writes:\n> >> > We have been talking about loose submodules for some time:\n> >> \n> >> Also before introducing a new terminology \"loose submodule\", please define\n> >> it somewhere. It feels confusing to me that a normal submodule, which\n> >> shouldn't be auto-cloned nor auto-updated without \"submodule init\", needs\n> >> to be called by a name other than simply a \"submodule\" but with an\n> >> adjuctive \"loose submodule\".\n> >\n> > Thats why I avoided talking about it in the docs. For the commit message\n> > I thought it would be kind of intuitive but I can update the commit\n> > message so that it becomes more clear.\n> \n> That sounds like a good thing to do.\n\nI discovered that I only talked in the cover letter about the term\n'loose'. Since that will not go into any commit I guess we can keep the\nseries this way?\n\nCheers Heiko\n"},{"id":"174053","messageId":"7v62lpuky8.fsf@alter.siamese.dyndns.org","threadId":"28070","inReplyTo":"20110822200052.GC11745@sandbox-rc","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-22T22:42:55Z","receivedAt":"2011-08-22T22:42:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> On Mon, Aug 15, 2011 at 01:37:53PM -0700, Junio C Hamano wrote:\n>> Heiko Voigt writes:\n>> \n>> > On Thu, Aug 11, 2011 at 11:28:31AM -0700, Junio C Hamano wrote:\n>> >> Heiko Voigt writes:\n>> >> > We have been talking about loose submodules for some time:\n>> >> \n>> >> Also before introducing a new terminology \"loose submodule\", please define\n>> ... \n>> That sounds like a good thing to do.\n> \n> I discovered that I only talked in the cover letter about the term\n> 'loose'. Since that will not go into any commit I guess we can keep the\n> series this way?\n\nYes, except that I do not have a clear answer to my other half of the\nquestion in the same message you omitted from your quote.\n\n>> What I usually do is say \"submodule init\" without any extra option once.\n>> That will register all submodules from .gitmodules in the config. Now\n>> when I say \"submodule update\" all submodules would be cloned. In the\n>> case of recursive submodules actually\n>>\n>> \tgit submodule update --init --recursive\n>>\n>> is the only command which can get you really everything in one go.\n>>\n>> Do you think the \"submodule init\" behavior is wrong? If so I think its a\n>> bit late to change this since people using submodules (me included)\n>> already have got used to it.\n>>\n>> With this config variable all submodules will still be registered to\n>> .git/config on \"submodule init\" but \"submodule update\" will skip those\n>> submodules.\n>\n> Ok, that sort-of makes sense, but we have been using \"do we have the\n> submodule registered in the .git/config of the superproject?\" to decide\n> \"does the user interested in having a checkout of the submodule?\" (I think\n> in the ancient days it was \"do we have .git in that submodule directory?\"\n> that decided it, but we dropped that because it won't work when switching\n> branches that has and does not have the submodule in superproject).\n>\n> It is somewhat worrying that some parts of the system may still be using\n> that old criteria \"do we have it in .git/config of the superproject?\" to\n> decide if the user is interested in the submodule. If so they need to be\n> updated to take this new semantics \"do we have it in .git/config without\n> its submodule.$name.update set to none\" into account. We would probably\n> need to have a paragraph in the release notes to warn about the semantics\n> change (which I tend to agree with you that it is a good one).\n"},{"id":"174114","messageId":"20110823194350.GA57187@book.hvoigt.net","threadId":"28070","inReplyTo":"7v62lpuky8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-23T19:43:50Z","receivedAt":"2011-08-23T19:43:50Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Mon, Aug 22, 2011 at 03:42:55PM -0700, Junio C Hamano wrote:\n> > On Mon, Aug 15, 2011 at 01:37:53PM -0700, Junio C Hamano wrote:\n> >> Heiko Voigt writes:\n> >> What I usually do is say \"submodule init\" without any extra option once.\n> >> That will register all submodules from .gitmodules in the config. Now\n> >> when I say \"submodule update\" all submodules would be cloned. In the\n> >> case of recursive submodules actually\n> >>\n> >> \tgit submodule update --init --recursive\n> >>\n> >> is the only command which can get you really everything in one go.\n> >>\n> >> Do you think the \"submodule init\" behavior is wrong? If so I think its a\n> >> bit late to change this since people using submodules (me included)\n> >> already have got used to it.\n> >>\n> >> With this config variable all submodules will still be registered to\n> >> .git/config on \"submodule init\" but \"submodule update\" will skip those\n> >> submodules.\n> >\n> > Ok, that sort-of makes sense, but we have been using \"do we have the\n> > submodule registered in the .git/config of the superproject?\" to decide\n> > \"does the user interested in having a checkout of the submodule?\" (I think\n> > in the ancient days it was \"do we have .git in that submodule directory?\"\n> > that decided it, but we dropped that because it won't work when switching\n> > branches that has and does not have the submodule in superproject).\n> >\n> > It is somewhat worrying that some parts of the system may still be using\n> > that old criteria \"do we have it in .git/config of the superproject?\" to\n> > decide if the user is interested in the submodule. If so they need to be\n> > updated to take this new semantics \"do we have it in .git/config without\n> > its submodule.$name.update set to none\" into account. We would probably\n> > need to have a paragraph in the release notes to warn about the semantics\n> > change (which I tend to agree with you that it is a good one).\n\nSorry that I forgot to answer to this. I am not sure what you mean by\n\"the semantics change\". This patch does not change any existing\nbehavior. I rather see this as an extra way to specify the default\nbehavior of what happens on submodule update. If people do not use it\nthere will be no expectations broken.\n\nAnother change I am thinking of (which would definitely need an entry in\nthe release notes) is to change submodule foreach to iterate over all\ngitmodule entries in the index/HEAD/worktree (not sure yet) instead of\n\"just entries that are in .git/config\".\n\nWhat do you think?\n\nCheers Heiko\n"},{"id":"174118","messageId":"4E540B03.2030909@web.de","threadId":"28070","inReplyTo":"20110823194350.GA57187@book.hvoigt.net","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-08-23T20:18:11Z","receivedAt":"2011-08-23T20:18:11Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 23.08.2011 21:43, schrieb Heiko Voigt:\n> On Mon, Aug 22, 2011 at 03:42:55PM -0700, Junio C Hamano wrote:\n>>> It is somewhat worrying that some parts of the system may still be using\n>>> that old criteria \"do we have it in .git/config of the superproject?\" to\n>>> decide if the user is interested in the submodule. If so they need to be\n>>> updated to take this new semantics \"do we have it in .git/config without\n>>> its submodule.$name.update set to none\" into account. We would probably\n>>> need to have a paragraph in the release notes to warn about the semantics\n>>> change (which I tend to agree with you that it is a good one).\n> \n> Sorry that I forgot to answer to this. I am not sure what you mean by\n> \"the semantics change\". This patch does not change any existing\n> behavior. I rather see this as an extra way to specify the default\n> behavior of what happens on submodule update. If people do not use it\n> there will be no expectations broken.\n\nIt might surprise people. E.g. when their old scripts don't work anymore as\nthey did before because a submodule won't be populated or updated in the work\ntree even though it is present in .git/config. So I agree that this should be\ndocumented in the release notes so people can check if their expectations are\nstill met.\n\n> Another change I am thinking of (which would definitely need an entry in\n> the release notes) is to change submodule foreach to iterate over all\n> gitmodule entries in the index/HEAD/worktree (not sure yet) instead of\n> \"just entries that are in .git/config\".\n\nWhen changing the default I think we'll surprise a lot of users (imagine\nsomeone running a \"git submodule foreach pwd\" when some submodules aren't\npopulated). But adding an option to \"git submodule foreach\" (and maybe others)\nto get the list of submodules from the index or HEAD might make sense (while\nI'm not sure parsing the work tree does, as you'll basically have to pick up\nany .git you find. AFAICS a submodule is defined either by an entry in the\n.gitmodules file, in .git/config or through a gitlink entry in a commit or the\nindex. So maybe the third alternative to index and HEAD is to use those found\nin .gitmodules?).\n\nCould you describe a use case for that?\n"},{"id":"174124","messageId":"7vpqjvrebk.fsf@alter.siamese.dyndns.org","threadId":"28070","inReplyTo":"4E540B03.2030909@web.de","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-23T21:46:39Z","receivedAt":"2011-08-23T21:46:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> It might surprise people. E.g. when their old scripts don't work anymore as\n> they did before because a submodule won't be populated or updated in the work\n> tree even though it is present in .git/config. So I agree that this should be\n> documented in the release notes so people can check if their expectations are\n> still met.\n\nWorse yet, their custom old scripts that they use to update submodules in\ntheir repository, if properly written, assume that anything registered in\nthe .git/config file as [submodule \"foo\"] _must_ be populated, but they\ncan no longer assume that and now has to look at submodule.foo.update and\nif it notices the variable is set to \"none\" leave the submodule repository\nalone. Having \"submodule.foo\" registered in the .git/config file alone\nused to mean the user is interested in \"foo\" submodule and wants to have a\ncheckout for it, now it does not necessarily mean that.\n\nThat is definitely a huge semantics change.\n"},{"id":"174179","messageId":"20110824193007.GC45292@book.hvoigt.net","threadId":"28070","inReplyTo":"7vpqjvrebk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-24T19:30:08Z","receivedAt":"2011-08-24T19:30:08Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Tue, Aug 23, 2011 at 02:46:39PM -0700, Junio C Hamano wrote:\n> Jens Lehmann writes:\n> \n> > It might surprise people. E.g. when their old scripts don't work anymore as\n> > they did before because a submodule won't be populated or updated in the work\n> > tree even though it is present in .git/config. So I agree that this should be\n> > documented in the release notes so people can check if their expectations are\n> > still met.\n> \n> Worse yet, their custom old scripts that they use to update submodules in\n> their repository, if properly written, assume that anything registered in\n> the .git/config file as [submodule \"foo\"] _must_ be populated, but they\n> can no longer assume that and now has to look at submodule.foo.update and\n> if it notices the variable is set to \"none\" leave the submodule repository\n> alone. Having \"submodule.foo\" registered in the .git/config file alone\n> used to mean the user is interested in \"foo\" submodule and wants to have a\n> checkout for it, now it does not necessarily mean that.\n> \n> That is definitely a huge semantics change.\n\nOk seeing it that way. You are right. How about this?\n\n-8<---\nFrom: Heiko Voigt \nSubject: [PATCH] mention the new submodule.$name.update=none flag in the\n ReleaseNotes\n\n---\n Documentation/RelNotes/1.7.7.txt | 4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/RelNotes/1.7.7.txt b/Documentation/RelNotes/1.7.7.txt\nindex 8de880f..b8edcf1 100644\n--- a/Documentation/RelNotes/1.7.7.txt\n+++ b/Documentation/RelNotes/1.7.7.txt\n@@ -71,6 +71,10 @@ Updates since v1.7.6\n submodule; it now goes on to update other submodules that can be\n updated, and reports the ones with errors at the end.\n \n+ * \"git submodule update\" does not clone/update a submodule when\n+ submodule.$name.update is set to 'none'. This option is copied from\n+ .gitmodules when a submodule is initialized.\n+\n * \"git upload-pack\" and \"git receive-pack\" learned to pretend only a\n subset of the refs exist in a repository. This may help a site to\n put many tiny repositories into one repository (this would not be\n-- \n1.7.6.551.g4266ca\n"},{"id":"174187","messageId":"20110824203816.GG45292@book.hvoigt.net","threadId":"28070","inReplyTo":"4E540B03.2030909@web.de","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-24T20:38:16Z","receivedAt":"2011-08-24T20:38:16Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Aug 23, 2011 at 10:18:11PM +0200, Jens Lehmann wrote:\n> Am 23.08.2011 21:43, schrieb Heiko Voigt:\n> > Another change I am thinking of (which would definitely need an entry in\n> > the release notes) is to change submodule foreach to iterate over all\n> > gitmodule entries in the index/HEAD/worktree (not sure yet) instead of\n> > \"just entries that are in .git/config\".\n> \n> When changing the default I think we'll surprise a lot of users (imagine\n> someone running a \"git submodule foreach pwd\" when some submodules aren't\n> populated). But adding an option to \"git submodule foreach\" (and maybe others)\n> to get the list of submodules from the index or HEAD might make sense (while\n> I'm not sure parsing the work tree does, as you'll basically have to pick up\n> any .git you find. AFAICS a submodule is defined either by an entry in the\n> .gitmodules file, in .git/config or through a gitlink entry in a commit or the\n> index. So maybe the third alternative to index and HEAD is to use those found\n> in .gitmodules?).\n> \n> Could you describe a use case for that?\n\nYes, a repository using the submodule.$name.checkout=none config.\n\nCurrently its hard to iterate over all submodules to set this config to\n'checkout' locally. You can not use submodule foreach for that since it\nwill skip submodule directories that do not have .git in them.\n\nBut you are right this should obviously be done using an option like\n\n\tgit submodule foreach --head ...\n\nor similar.\n\nCheers Heiko\n"},{"id":"174302","messageId":"7vbovcg00u.fsf@alter.siamese.dyndns.org","threadId":"28070","inReplyTo":"20110824193007.GC45292@book.hvoigt.net","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-26T06:27:45Z","receivedAt":"2011-08-26T06:27:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n>> That is definitely a huge semantics change.\n>\n> Ok seeing it that way. You are right. How about this?\n\nActually I had an update to Documentation/git-submodule.txt in mind. For\nexample, we say this for \"update\":\n\n Update the registered submodules, i.e. clone missing submodules and\n checkout the commit specified in the index of the containing repository.\n\nI know you added \"yes, we earlier said this will clone missing ones and\ncheckout, but if this configuration is set to none then none of that\nhappens\" much later in the section, but that feels backwards.\n\nThinking about it more, I am starting to think that this backwardness may\nbe an indication that we are describing a wrong solution to a wrong\nproblem.\n\nIsn't the root cause of the issue that a \"submodule init\" without pathspec\nlimit adds everything to .git/config, ending up with all submodules fully\ninstantiated, and it is too easy to run such a lazy \"submodule init\"?\n\nIf we allowed the project managers (i.e. the ones who write .gitmodules)\nto specify the default set of submodules to be initialized with such a\n\"submodule init\", omitting some submodules from even getting registered to\nthe recipients' .git/config in the first place, wouldn't that solve the\nissue you are trying to address equally well, without anything to worry\nabout this semantic change at all? I am trying to see if we can come up\nwith a solution with which we do not even have to add any entry for a\nsubmodule to .git/config of the superproject, if it is \"don't care\" kind\nof submodule for the copy of the superproject repository the user has.\n\nThe way in which the project managers specify that a module is not meant\nto be \"init\"ed by default may be to have \"submodule.$name.update = none\"\nin the .gitmodules file they ship, so externally there may not be huge\ndifference from the behaviour (but not the implementation) of your patch,\neven though submodule.$name.update probably is not a good variable name to\nbe used for this purpose.\n\nAnother thing we may want to consider is to make .gitmodules describe\nsubmodule dependencies. If your hypothetical superproject is about a\nlibrary, which consists of doc/, include/, and libsrc/ submodules, with\npre-built binary perhaps shipped as part of the superproject itself, those\nwho work on documentation may want to populate only doc/, those who are\ninterested in using the library may want to populate only include/ and\npossibly doc/, and those who work on the library itself would populate\ninclude/ and libsrc/, possibly with doc/ submodules. It wouldn't make any\nsense to populate libsrc/ without populating include/ submodule, as the\nsource would not be buildable without the includes.\n\nNow if we imagine that much more people are interested in using the\nlibrary than working on it, it is plausible that the project may want to\nsuggest:\n\n - Majority of people may want to omit libsrc/ submodule; and\n\n - If you populate libsrc/, then you would definitely want to populate\n include/ submodule.\n\nYour \"submodule.libsrc.update = none\" in .gitmodules can express the\nformer, and I think it is natural to express the latter (i.e. submodule\ndependency) in the same file, to be propagated in the same way to the\nconsumers.\n"},{"id":"174325","messageId":"4E57C679.9080406@web.de","threadId":"28070","inReplyTo":"7vbovcg00u.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] Add an update=none option for 'loose' submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-08-26T16:14:49Z","receivedAt":"2011-08-26T16:14:49Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.08.2011 08:27, schrieb Junio C Hamano:\n> Thinking about it more, I am starting to think that this backwardness may\n> be an indication that we are describing a wrong solution to a wrong\n> problem.\n\nI Agree, I see two related topics mingled here.\n\n> Isn't the root cause of the issue that a \"submodule init\" without pathspec\n> limit adds everything to .git/config, ending up with all submodules fully\n> instantiated, and it is too easy to run such a lazy \"submodule init\"?\n\nYes. And that upstream has no option (yet) to tell which submodules should\nbe automatically initialized on clone, which would get rid of the need to\nrun \"git submodule init\" in the first place for the average user.\n\nTo me Heiko's change fixes that issue `accidentally` because \"update=none\"\nimplies \"even when it is initialized I never want to update its work tree,\nso don't even clone it\". Which is correct but not quite the meaning of the\nupdate config.\n\n> If we allowed the project managers (i.e. the ones who write .gitmodules)\n> to specify the default set of submodules to be initialized with such a\n> \"submodule init\", omitting some submodules from even getting registered to\n> the recipients' .git/config in the first place, wouldn't that solve the\n> issue you are trying to address equally well, without anything to worry\n> about this semantic change at all? I am trying to see if we can come up\n> with a solution with which we do not even have to add any entry for a\n> submodule to .git/config of the superproject, if it is \"don't care\" kind\n> of submodule for the copy of the superproject repository the user has.\n\nI really think we need such an option. I imagine enabling it to even\ninitialize the submodules on clone or when checking out a branch\nintroducing a new submodule (and fetch should proactively fetch such\nsubmodules so they can be checked out when disconnected later). Working\ntitle: \"init=[auto|no]\", with \"auto\" initializing it on clone and \"none\"\nnever initializing it unless the submodule is given on the command line.\n\n> The way in which the project managers specify that a module is not meant\n> to be \"init\"ed by default may be to have \"submodule.$name.update = none\"\n> in the .gitmodules file they ship, so externally there may not be huge\n> difference from the behaviour (but not the implementation) of your patch,\n> even though submodule.$name.update probably is not a good variable name to\n> be used for this purpose.\n\nIMO the update option is about what should happen to an initialized\nsubmodule when a the commit recorded in the superproject changes: Shall it\nbe checked out, rebased, merged or left alone. Heiko's proposal adds the\nmissing fourth case, so I think his patch is going in the right direction.\nBut we should have another config option to state \"not to be initialized\".\n\n> Another thing we may want to consider is to make .gitmodules describe\n> submodule dependencies. If your hypothetical superproject is about a\n> library, which consists of doc/, include/, and libsrc/ submodules, with\n> pre-built binary perhaps shipped as part of the superproject itself, those\n> who work on documentation may want to populate only doc/, those who are\n> interested in using the library may want to populate only include/ and\n> possibly doc/, and those who work on the library itself would populate\n> include/ and libsrc/, possibly with doc/ submodules. It wouldn't make any\n> sense to populate libsrc/ without populating include/ submodule, as the\n> source would not be buildable without the includes.\n\nYes, it would be cool having a \"git submodule init libsrc\" initializing\nsubmodule \"include\" too.\n\n> Now if we imagine that much more people are interested in using the\n> library than working on it, it is plausible that the project may want to\n> suggest:\n> \n> - Majority of people may want to omit libsrc/ submodule; and\n> \n> - If you populate libsrc/, then you would definitely want to populate\n> include/ submodule.\n> \n> Your \"submodule.libsrc.update = none\" in .gitmodules can express the\n> former, and I think it is natural to express the latter (i.e. submodule\n> dependency) in the same file, to be propagated in the same way to the\n> consumers.\n\nAs I said above, I think \"submodule.libsrc.update = none\" only does the\ntrick because \"git submodule update\" is used to both clone an update a\nsubmodule. I vote for a separate option to express the first condition.\n\nFor me this is thread covers three different issues:\n\n1) What submodules should be initialized?\n I think we need to add a new option (\"init\"?) to control that.\n\n2) How should initialized submodules be updated when the SHA1 changes?\n This is what \"update\" should control, and Heiko's patch adds the\n missing \"none\" case.\n\n3) What dependencies do submodules have?\n This is slightly orthogonal but should honor the settings in 1) and 2).\n\nAnd I believe there are use cases where you want the submodule to be\ninitialized but never updated (and I expect \"ignore=all\" to be set in\nthat case too, as the user should not be bothered if the submodule is out\nof sync). Imagine large intro movies of a gaming project separated into a\nsubmodule which each developer should have to start the application but\ndoesn't care if he doesn't have the most up-to-date version.\n\nSo before people start (mis-)using the \"update=none\" option because they\ncan't use \"init=none\" yet, I vote for an additional patch implementing\nthat config option (per submodule and globally). Then we can document each\noption properly.\n\nDoes that make sense?\n"}]}