{"thread":{"id":"33731","subject":"Fwd: Uninit'ed submodules","startedAt":"2013-05-06T00:19:26Z","lastAt":"2013-05-07T08:01:04Z","messageCount":3,"participants":["Chris Packham","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"216471","messageId":"CAFOYHZDKTYFNRHUwdas7kZKs8UbdrY=hAA0SVqbz48NjWsHKww@mail.gmail.com","threadId":"33731","inReplyTo":"CAFOYHZCfL2uqnUkb=7kSdpudKvYrfMo9saJ8eNsj5mYDQgHVuA@mail.gmail.com","subject":"Fwd: Uninit'ed submodules","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-05-06T00:19:26Z","receivedAt":"2013-05-06T00:19:26Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi,\n\n[Jens, sorry for the re-send - trying to convince gmail to send plain text.]\n\nJust ran into a submodules usability situation at $dayjob that might\nbe worth looking at.\n\nAn internal maintainer was going to pull changes in from a project\nteam into our repository which is arranged into submodules for various\ncomponents. The maintainer decided that the best thing for him would\nbe to create a new working area to do the merging so he re-cloned the\nsuper project (with default settings of git 1.7.9.5).\n\nWhat he then forgot to do is \"git submodule update --init\" but because\nthe empty submodules were real directories he was able to continue\nwith what he thought was the right procedure of \"cd submodule && git\npull project/submodule.git\". He did notice the no changes in common\nmessage and a whole bunch of unexpected modifications at which point\nhe grabbed me so no harm done.\n\nThis did get me thinking. Why does an uninitialized submodule need to\nhave an empty directory? If it didn't the maintainer in question\nprobably would have realized that he needed to run \"git submodule\nupdate --init\" when his \"cd submodule\" command failed.\n\nI'm guessing there is a good reason for the empty directory - perhaps\nso that git can notice the fact that it exists in the worktree but is\nout of date?  If it does need to have some presence in the worktree\nwhy not as a file? That way the cd command would still fail (albeit\nwith a different error) providing the necessary indication to the\nuser. The submodule update --init could then change from file -> dir\nwhen it actually gets populated.\n\nThanks for reading,\nChris\n"},{"id":"216534","messageId":"51880191.2070809@web.de","threadId":"33731","inReplyTo":"CAFOYHZDKTYFNRHUwdas7kZKs8UbdrY=hAA0SVqbz48NjWsHKww@mail.gmail.com","subject":"Re: Fwd: Uninit'ed submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-05-06T19:16:33Z","receivedAt":"2013-05-06T19:16:33Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 06.05.2013 02:19, schrieb Chris Packham:\n> This did get me thinking. Why does an uninitialized submodule need to\n> have an empty directory? If it didn't the maintainer in question\n> probably would have realized that he needed to run \"git submodule\n> update --init\" when his \"cd submodule\" command failed.\n> \n> I'm guessing there is a good reason for the empty directory - perhaps\n> so that git can notice the fact that it exists in the worktree but is\n> out of date?  If it does need to have some presence in the worktree\n> why not as a file? That way the cd command would still fail (albeit\n> with a different error) providing the necessary indication to the\n> user. The submodule update --init could then change from file -> dir\n> when it actually gets populated.\n\nHmm, to me an empty directory is the natural representation of an\nunpopulated submodule, but I see why that made it hard for your\nmaintainer to notice the fact that the submodule was uninitialized.\nI suspect changing an unpopulated submodule to be represented by a\nfile will surprise quite some users (some of which will probably\ncome up with perfectly valid use cases such a change will break).\n\nWhat about the following: Today's Git completely ignores empty\nsubmodule directories, but I think that when the recursive checkout\nsupport is there, the \"submodule.autoupdate\" flag - which I believe\nshould control that behavior - could also make those empty submodule\ndirectories show up in \"git status\" as being unpopulated (after all\nthey are configured to be updated automatically, so not having them\npopulated is something Git should show). Would something like this\nhave helped here?\n\nUntil then I can only propose to establish a best practice of using\n\"git clone --recurse-submodules\" in these situations to avoid the\nproblem you described.\n"},{"id":"216608","messageId":"5188B4C0.50206@gmail.com","threadId":"33731","inReplyTo":"51880191.2070809@web.de","subject":"Re: Fwd: Uninit'ed submodules","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-05-07T08:01:04Z","receivedAt":"2013-05-07T08:01:04Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 07/05/13 07:16, Jens Lehmann wrote:\n> Am 06.05.2013 02:19, schrieb Chris Packham:\n>> This did get me thinking. Why does an uninitialized submodule need to\n>> have an empty directory? If it didn't the maintainer in question\n>> probably would have realized that he needed to run \"git submodule\n>> update --init\" when his \"cd submodule\" command failed.\n>>\n>> I'm guessing there is a good reason for the empty directory - perhaps\n>> so that git can notice the fact that it exists in the worktree but is\n>> out of date?  If it does need to have some presence in the worktree\n>> why not as a file? That way the cd command would still fail (albeit\n>> with a different error) providing the necessary indication to the\n>> user. The submodule update --init could then change from file -> dir\n>> when it actually gets populated.\n> \n> Hmm, to me an empty directory is the natural representation of an\n> unpopulated submodule, but I see why that made it hard for your\n> maintainer to notice the fact that the submodule was uninitialized.\n> I suspect changing an unpopulated submodule to be represented by a\n> file will surprise quite some users (some of which will probably\n> come up with perfectly valid use cases such a change will break).\n> \n> What about the following: Today's Git completely ignores empty\n> submodule directories, but I think that when the recursive checkout\n> support is there, the \"submodule.autoupdate\" flag - which I believe\n> should control that behavior - could also make those empty submodule\n> directories show up in \"git status\" as being unpopulated (after all\n> they are configured to be updated automatically, so not having them\n> populated is something Git should show). Would something like this\n> have helped here?\n> \n> Until then I can only propose to establish a best practice of using\n> \"git clone --recurse-submodules\" in these situations to avoid the\n> problem you described.\n> \n\nYeah I think training people to use --recurse-submodules is probably the\nbest thing we can do with the current version of git on our developers\nwork stations. There is a bit of an issue when we add a new submodule\n(people aren't used to using submodule update --init), but that isn't a\nfrequent occurrence.\n\nThe recursive checkout sounds like something we'd benefit from.\n"}]}