[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 220.127.116.11).
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,
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