{"thread":{"id":"35488","subject":"git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","startedAt":"2013-12-06T15:48:46Z","lastAt":"2013-12-12T21:17:48Z","messageCount":10,"participants":["Charlie Dyson","Heiko Voigt","Junio C Hamano","Jens Lehmann","W. Trevor King","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"231657","messageId":"CABYr9QtSeX=Euf73MZPq6suo+GpVA=f+tH73Ct0tP-3LYogh9w@mail.gmail.com","threadId":"35488","inReplyTo":null,"subject":"git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"Charlie Dyson","fromEmail":"charlie@charliedyson.net","sentAt":"2013-12-06T15:48:46Z","receivedAt":"2013-12-06T15:48:46Z","isPatch":false,"sender":{"key":"charlie@charliedyson.net","avatar":null},"body":"gitmodules(5) states that submodule.$name.update should be defined in\n.gitmodules. However in cmd_update() in git-submodule.sh, git config\nis used with \"-f .gitmodules\". Consequently this flag is only\nrespected in .git/config\n\nTested against: 1.8.2.1 [sorry! I've checked the relevant bit of\nsource and it's the same]\n\nSteps to reproduce:\n$ git init\n$ git submodule add -b master someproject\n$ git config -f .gitmodules --add submodule.someproject.update merge\n$ # Go to someproject and commit something\n$ git submodule update --remote\n\nThe latter does not perform a merge, and behaviour is visibly\ndifferent to adding --merge.\n\nI would submit a patch but I'm not completely sure what the behaviour\nwould be - simply adding \"-f .gitmodules\" would hurt users that have\nadopted the practice of specifying their update preference in\n.git/config.\n\nPerhaps the right thing to do is read from .git/config and fall back\nto .gitmodules using get_submodule_config().\n\nCheers,\n\nCharlie\n"},{"id":"231834","messageId":"20131209223506.GF9606@sandbox-ub","threadId":"35488","inReplyTo":"CABYr9QtSeX=Euf73MZPq6suo+GpVA=f+tH73Ct0tP-3LYogh9w@mail.gmail.com","subject":"Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2013-12-09T22:35:06Z","receivedAt":"2013-12-09T22:35:06Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Fri, Dec 06, 2013 at 03:48:46PM +0000, Charlie Dyson wrote:\n> gitmodules(5) states that submodule.$name.update should be defined in\n> .gitmodules. However in cmd_update() in git-submodule.sh, git config\n> is used with \"-f .gitmodules\". Consequently this flag is only\n> respected in .git/config\n> \n> Tested against: 1.8.2.1 [sorry! I've checked the relevant bit of\n> source and it's the same]\n> \n> Steps to reproduce:\n> $ git init\n> $ git submodule add -b master someproject\n> $ git config -f .gitmodules --add submodule.someproject.update merge\n> $ # Go to someproject and commit something\n> $ git submodule update --remote\n> \n> The latter does not perform a merge, and behaviour is visibly\n> different to adding --merge.\n\nThis is because of histerical reasons. When submodules were first\nimplemented the notion was that .gitmodules should only be used as a\nstarting point to initialise the configuration in .git/config when init\nwas called.\n\nThis notion has changed in a way that only the url (by that the name)\nshould be copied on init. The default for everything else should come\nfrom .gitmodules or gits own default.\n\nThe update configuration option was implemented before we realized that.\nSo currently it is still copied when submodule init is called. The main\nreason is that we have not found the time to change that.\n\n> I would submit a patch but I'm not completely sure what the behaviour\n> would be - simply adding \"-f .gitmodules\" would hurt users that have\n> adopted the practice of specifying their update preference in\n> .git/config.\n\nWell .gitmodules should only be the fallback if there is nothing in\n.git/config.\n\n> Perhaps the right thing to do is read from .git/config and fall back\n> to .gitmodules using get_submodule_config().\n\nYes IMO that is the right thing to do. If you implement it that way (and\nremove the automatic copying on init) you should not break peoples\nexpectations. So if you want to go ahead please send a patch.\n\nCheers Heiko\n"},{"id":"231841","messageId":"xmqqlhztvbi8.fsf@gitster.dls.corp.google.com","threadId":"35488","inReplyTo":"20131209223506.GF9606@sandbox-ub","subject":"Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-09T23:40:47Z","receivedAt":"2013-12-09T23:40:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt <hvoigt@hvoigt.net> writes:\n\n> This notion has changed in a way that only the url (by that the name)\n> should be copied on init. The default for everything else should come\n> from .gitmodules or gits own default.\n\nI think you need to be a bit careful here.  I do not think\neverything should blindly default to .gitmodules (otherwise there\nare obvious security implications as well as usability ones).\n\n> The update configuration option was implemented before we realized that.\n> So currently it is still copied when submodule init is called. The main\n> reason is that we have not found the time to change that.\n\nAnd 'update', as it allows any custom way to run it, is unlikely to\nbe allowed to be used blindly from .gitmodules, no?\n"},{"id":"231929","messageId":"52A8E689.80701@web.de","threadId":"35488","inReplyTo":"xmqqlhztvbi8.fsf@gitster.dls.corp.google.com","subject":"Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-12-11T22:26:17Z","receivedAt":"2013-12-11T22:26:17Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 10.12.2013 00:40, schrieb Junio C Hamano:\n> Heiko Voigt <hvoigt@hvoigt.net> writes:\n> \n>> This notion has changed in a way that only the url (by that the name)\n>> should be copied on init. The default for everything else should come\n>> from .gitmodules or gits own default.\n> \n> I think you need to be a bit careful here.  I do not think\n> everything should blindly default to .gitmodules (otherwise there\n> are obvious security implications as well as usability ones).\n\nI believe everything except the URL should default to .gitmodules,\nfor the same reasons we already do that for fetch and ignore [1].\nBut it should not do so blindly and take precautions that this\nonly happens for safe values.\n\nThe only current exception is the update setting, but I'd like to\nchange that in two steps:\n\n1) Teach git-submodule.sh to fall back to the update setting from\n   .gitmodules if none is found in .git/config (more details below)\n\n2) Wait some time and remove the copying on init later (to make\n   life easier for people who are working on the same checkout\n   with different versions of git).\n\n>> The update configuration option was implemented before we realized that.\n>> So currently it is still copied when submodule init is called. The main\n>> reason is that we have not found the time to change that.\n> \n> And 'update', as it allows any custom way to run it, is unlikely to\n> be allowed to be used blindly from .gitmodules, no?\n\nDefinitely not. And while thinking about it it might make sense to\npass a list of allowed values for all configurations to the\nget_submodule_config() function, making sure that fallbacks are only\nused when they are safe.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/161193/focus=161357\n"},{"id":"231930","messageId":"20131211224424.GB25409@odin.tremily.us","threadId":"35488","inReplyTo":"52A8E689.80701@web.de","subject":"Re: Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-12-11T22:44:24Z","receivedAt":"2013-12-11T22:44:24Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Wed, Dec 11, 2013 at 11:26:17PM +0100, Jens Lehmann wrote:\n> Am 10.12.2013 00:40, schrieb Junio C Hamano:\n> > Heiko Voigt <hvoigt@hvoigt.net> writes:\n> >> This notion has changed in a way that only the url (by that the\n> >> name) should be copied on init. The default for everything else\n> >> should come from .gitmodules or gits own default.\n> > \n> > I think you need to be a bit careful here.  I do not think\n> > everything should blindly default to .gitmodules (otherwise there\n> > are obvious security implications as well as usability ones).\n> \n> I believe everything except the URL should default to .gitmodules,\n> for the same reasons we already do that for fetch and ignore [1].\n> But it should not do so blindly and take precautions that this only\n> happens for safe values.\n\nI think the \"safety of .git/config vs. convenience of .gitmodules\"\nbalance is going to break down differently for different folks.\nThat's why I proposed get_submodule_config() [1] and\nsubmodule.<name>.active as an activation marker [2,3].  Then users can\nmove as much or as little of the submodule config from .gitmodules\ninto .git/config to strike the balance they feel is appropriate.  For\nsafety, maybe the default `init` should copy *everything* into\n.git/config, after which users can remove stuff they'd like to\ndelegate to .gitmodules.\n\nCheers,\nTrevor\n\n[1]: http://article.gmane.org/gmane.comp.version-control.git/210930\n[2]: http://article.gmane.org/gmane.comp.version-control.git/211014\n[3]: http://article.gmane.org/gmane.comp.version-control.git/211042\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"231937","messageId":"7vtxeeuaw7.fsf@alter.siamese.dyndns.org","threadId":"35488","inReplyTo":"20131211224424.GB25409@odin.tremily.us","subject":"Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-12T01:16:08Z","receivedAt":"2013-12-12T01:16:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" <wking@tremily.us> writes:\n\n> For\n> safety, maybe the default `init` should copy *everything* into\n> .git/config, after which users can remove stuff they'd like to\n> delegate to .gitmodules.\n\nCopying everything into config is \"be unsafe and inconvenient by\ndefault for everybody\", isn't it?  Folks who want safety are forced\nto inspect the resulting entries in their config file (which is more\ninconvenent if you compare with the design where nothing is copied\nand nothing dynamically defaults to what then-current .gitmodules\nhappens to contain).  Folks who trust those who update .gitmodules\nfor them are forced to update their config every time upstream\ndecides to use different settings in .gitmodules, because they have\nstale values in their config that mask what are in .gitmodules.\n\nI think the solution we want is to copy only minimum to the config\n(and that \"minimum\" may turn out to be \"nothing\"), and to default\nkeys that are only absolutely safe to .gitmodules file.\n"},{"id":"231952","messageId":"52AA072F.2000105@web.de","threadId":"35488","inReplyTo":"7vtxeeuaw7.fsf@alter.siamese.dyndns.org","subject":"Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-12-12T18:57:51Z","receivedAt":"2013-12-12T18:57:51Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 12.12.2013 02:16, schrieb Junio C Hamano:\n> \"W. Trevor King\" <wking@tremily.us> writes:\n> \n>> For\n>> safety, maybe the default `init` should copy *everything* into\n>> .git/config, after which users can remove stuff they'd like to\n>> delegate to .gitmodules.\n> \n> Copying everything into config is \"be unsafe and inconvenient by\n> default for everybody\", isn't it?  Folks who want safety are forced\n> to inspect the resulting entries in their config file (which is more\n> inconvenent if you compare with the design where nothing is copied\n> and nothing dynamically defaults to what then-current .gitmodules\n> happens to contain).  Folks who trust those who update .gitmodules\n> for them are forced to update their config every time upstream\n> decides to use different settings in .gitmodules, because they have\n> stale values in their config that mask what are in .gitmodules.\n> \n> I think the solution we want is to copy only minimum to the config\n> (and that \"minimum\" may turn out to be \"nothing\"), and to default\n> keys that are only absolutely safe to .gitmodules file.\n\nI agree and will prepare a patch for that.\n\nWhat about teaching \"git submodule sync\" the \"--url\", \"--update\",\n\"--fetch\", \"--ignore\", \"--branch\" and \"--all\" options to allow the\nuser to copy the current settings he wants from .gitmodules to\n.git/config (but only safe values of course)? Trevor, would you be\nok to issue another command to copy everything to .git/config?\n"},{"id":"231954","messageId":"20131212191429.GI25409@odin.tremily.us","threadId":"35488","inReplyTo":"52AA072F.2000105@web.de","subject":"Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-12-12T19:14:29Z","receivedAt":"2013-12-12T19:14:29Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Dec 12, 2013 at 07:57:51PM +0100, Jens Lehmann wrote:\n> Am 12.12.2013 02:16, schrieb Junio C Hamano:\n> > I think the solution we want is to copy only minimum to the config\n> > (and that \"minimum\" may turn out to be \"nothing\"), and to default\n> > keys that are only absolutely safe to .gitmodules file.\n> \n> I agree and will prepare a patch for that.\n> \n> What about teaching \"git submodule sync\" the \"--url\", \"--update\",\n> \"--fetch\", \"--ignore\", \"--branch\" and \"--all\" options to allow the\n> user to copy the current settings he wants from .gitmodules to\n> .git/config (but only safe values of course)? Trevor, would you be\n> ok to issue another command to copy everything to .git/config?\n\nSounds good to me.  The more stuff I can leave in .gitmodules, the\nhappier I'll be ;).  My second step will be removing “unsafe” values\nfrom .git/config where possible, and I'll trust myself to check\n.gitmodules after pulls.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"231955","messageId":"20131212192301.GQ2311@google.com","threadId":"35488","inReplyTo":"52AA072F.2000105@web.de","subject":"Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-12-12T19:23:01Z","receivedAt":"2013-12-12T19:23:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jens Lehmann wrote:\n> Am 12.12.2013 02:16, schrieb Junio C Hamano:\n\n>> I think the solution we want is to copy only minimum to the config\n>> (and that \"minimum\" may turn out to be \"nothing\"), and to default\n>> keys that are only absolutely safe to .gitmodules file.\n>\n> I agree and will prepare a patch for that.\n>\n> What about teaching \"git submodule sync\" the \"--url\", \"--update\",\n> \"--fetch\", \"--ignore\", \"--branch\" and \"--all\" options to allow the\n> user to copy the current settings he wants from .gitmodules to\n> .git/config (but only safe values of course)?\n\nWhy would I want to copy settings to .git/config when they are safe\nenough to already be used directly from .gitmodules and the value from\n.gitmodules is the one chosen to make sense when working with the\ncurrent revision?\n\nURLs are kind of special because generally the newest value is the\nmost meaningful one, even when looking back over old history.\n\nThanks,\nJonathan\n"},{"id":"231962","messageId":"xmqqppp1sr9f.fsf@gitster.dls.corp.google.com","threadId":"35488","inReplyTo":"52AA072F.2000105@web.de","subject":"Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-12T21:17:48Z","receivedAt":"2013-12-12T21:17:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Am 12.12.2013 02:16, schrieb Junio C Hamano:\n>> \"W. Trevor King\" <wking@tremily.us> writes:\n>> \n>>> For\n>>> safety, maybe the default `init` should copy *everything* into\n>>> .git/config, after which users can remove stuff they'd like to\n>>> delegate to .gitmodules.\n>> \n>> Copying everything into config is \"be unsafe and inconvenient by\n>> default for everybody\", isn't it?  Folks who want safety are forced\n>> to inspect the resulting entries in their config file (which is more\n>> inconvenent if you compare with the design where nothing is copied\n>> and nothing dynamically defaults to what then-current .gitmodules\n>> happens to contain).  Folks who trust those who update .gitmodules\n>> for them are forced to update their config every time upstream\n>> decides to use different settings in .gitmodules, because they have\n>> stale values in their config that mask what are in .gitmodules.\n>> \n>> I think the solution we want is to copy only minimum to the config\n>> (and that \"minimum\" may turn out to be \"nothing\"), and to default\n>> keys that are only absolutely safe to .gitmodules file.\n>\n> I agree and will prepare a patch for that.\n>\n> What about teaching \"git submodule sync\" the \"--url\", \"--update\",\n> \"--fetch\", \"--ignore\", \"--branch\" and \"--all\" options to allow the\n> user to copy the current settings he wants from .gitmodules to\n> .git/config (but only safe values of course)?\n\nAn option per variable, which forms an unbounded set over time? From\nthe syntax point of view, \"--copy-config=url,update,...\"  probably\nis a better option, but I think that misses the point.  Copying will\nfreeze the choice in stone.\n\nAlso, as long as the copying is deliberately done with such an\noption, copying potentially \"unsafe\" ones is perfectly fine.\n\nReading and using what are not copied from the .gitmodules file _is_\na lot more severe security risk, so your \"only safe ones, of course\"\nshould apply more heavily on that side. In principle, by default, we\nshould use *nothing* from .gitmodules, and make exceptions on case\nby case basis, allowing only the safe ones.\n\nWhat is missing is a support for those like W. Trevor who trust what\nare in .gitmodules, and want to use values from there for ones we do\nnot add to that default list of exceptions. They are not helped by\nsuch an option to say \"copy these keys from .gitmodules to my\nconfig\". They do not want to freeze values to what was in there at\none point. They want to just follow along, whatever values happen to\nbe set in the .gitmodules file of the day.\n\nSo I _think_ a better approach would be to let users say something\nlike:\n\n\t[submodule \"frotz\"]\n        \tuseInTreeSetting = update ignore\n\nin their .git/config file in the repository of the top-level\nproject, to tell Git:\n\n    When 'submodule.frotz.update' or 'submodule.frotz.ignore' is\n    needed, please read from the .gitmodules file to grab the value\n    for that setting. I trust the project as a whole to set a\n    suitable value for me.\n\nand copy almost nothing to .git/config file upon 'init' time.\n\nIf we were to go this route, I would envision that this new variable\nwould be a list of keys to additionally allow defaulting to the\nvalues found in .gitmodules; if we hardcode 'branch', for example,\nas one of the keys that we fallback to .gitmodules, and if the user\ndoes *not* want to follow along to the project's recommendation,\nthe user can just set \"submodule.frotz.branch = <desired value>\" in\nthe .git/config file, and there is no need for the useIntreeSetting\nvariable to support \"Git by default may allow this variable 'branch'\nto be read from .gitmodules but I do not like that\".\n"}]}