Re: Fwd: Uninit'ed submodules

2013-05-07 Thread Chris Packham
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

2013-05-06 Thread Jens Lehmann
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