Re: Fwd: Uninit'ed submodules
On 07/05/13 07:16, Jens Lehmann wrote: > Am 06.05.2013 02:19, schrieb Chris Packham: >> This did get me thinking. Why does an uninitialized submodule need to >> have an empty directory? If it didn't the maintainer in question >> probably would have realized that he needed to run "git submodule >> update --init" when his "cd submodule" command failed. >> >> I'm guessing there is a good reason for the empty directory - perhaps >> so that git can notice the fact that it exists in the worktree but is >> out of date? If it does need to have some presence in the worktree >> why not as a file? That way the cd command would still fail (albeit >> with a different error) providing the necessary indication to the >> user. The submodule update --init could then change from file -> dir >> when it actually gets populated. > > Hmm, to me an empty directory is the natural representation of an > unpopulated submodule, but I see why that made it hard for your > maintainer to notice the fact that the submodule was uninitialized. > I suspect changing an unpopulated submodule to be represented by a > file will surprise quite some users (some of which will probably > come up with perfectly valid use cases such a change will break). > > What about the following: Today's Git completely ignores empty > submodule directories, but I think that when the recursive checkout > support is there, the "submodule.autoupdate" flag - which I believe > should control that behavior - could also make those empty submodule > directories show up in "git status" as being unpopulated (after all > they are configured to be updated automatically, so not having them > populated is something Git should show). Would something like this > have helped here? > > Until then I can only propose to establish a best practice of using > "git clone --recurse-submodules" in these situations to avoid the > problem you described. > Yeah I think training people to use --recurse-submodules is probably the best thing we can do with the current version of git on our developers work stations. There is a bit of an issue when we add a new submodule (people aren't used to using submodule update --init), but that isn't a frequent occurrence. The recursive checkout sounds like something we'd benefit from. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Uninit'ed submodules
Am 06.05.2013 02:19, schrieb Chris Packham: > This did get me thinking. Why does an uninitialized submodule need to > have an empty directory? If it didn't the maintainer in question > probably would have realized that he needed to run "git submodule > update --init" when his "cd submodule" command failed. > > I'm guessing there is a good reason for the empty directory - perhaps > so that git can notice the fact that it exists in the worktree but is > out of date? If it does need to have some presence in the worktree > why not as a file? That way the cd command would still fail (albeit > with a different error) providing the necessary indication to the > user. The submodule update --init could then change from file -> dir > when it actually gets populated. Hmm, to me an empty directory is the natural representation of an unpopulated submodule, but I see why that made it hard for your maintainer to notice the fact that the submodule was uninitialized. I suspect changing an unpopulated submodule to be represented by a file will surprise quite some users (some of which will probably come up with perfectly valid use cases such a change will break). What about the following: Today's Git completely ignores empty submodule directories, but I think that when the recursive checkout support is there, the "submodule.autoupdate" flag - which I believe should control that behavior - could also make those empty submodule directories show up in "git status" as being unpopulated (after all they are configured to be updated automatically, so not having them populated is something Git should show). Would something like this have helped here? Until then I can only propose to establish a best practice of using "git clone --recurse-submodules" in these situations to avoid the problem you described. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Uninit'ed submodules
Hi, [Jens, sorry for the re-send - trying to convince gmail to send plain text.] Just ran into a submodules usability situation at $dayjob that might be worth looking at. An internal maintainer was going to pull changes in from a project team into our repository which is arranged into submodules for various components. The maintainer decided that the best thing for him would be to create a new working area to do the merging so he re-cloned the super project (with default settings of git 1.7.9.5). What he then forgot to do is "git submodule update --init" but because the empty submodules were real directories he was able to continue with what he thought was the right procedure of "cd submodule && git pull project/submodule.git". He did notice the no changes in common message and a whole bunch of unexpected modifications at which point he grabbed me so no harm done. This did get me thinking. Why does an uninitialized submodule need to have an empty directory? If it didn't the maintainer in question probably would have realized that he needed to run "git submodule update --init" when his "cd submodule" command failed. I'm guessing there is a good reason for the empty directory - perhaps so that git can notice the fact that it exists in the worktree but is out of date? If it does need to have some presence in the worktree why not as a file? That way the cd command would still fail (albeit with a different error) providing the necessary indication to the user. The submodule update --init could then change from file -> dir when it actually gets populated. Thanks for reading, Chris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
