Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]

 > *Moving objects from submodule .git directories into the base .git/
 > directory would protect the submodules and is a good idea.


No, I did not say that.

 Even worse, I think that moving the .git/ directory into the
 superproject's .git/ would be at least quite a bit awkward in the nested
 case.

Tthe initial prompt for the proposal was: "Rewrite git-submodule,
placing the repository for each referenced submodules in the
superproject's $GIT_DIR/modules...This resolves issues related to
switching between versions of the superproject..." The prompt, and
past experience with git, helped me to form my proposal which it seems
would fix numerous problems with git submodule, with the implied cost
of some awkwardness/complexity. Am I misunderstanding the prompt? Or
do you think this could be accomplished more elegantly?

 I said that moving submodules' working directory need to protected when
 renaming/deleting submodules.

I'm sorry, I still don't understand. Where would this occur? What is
being protected? What is the submodules' working directory? I'm still
learning the intricacies of git, so I'd appreciate any pointers you
can give.

 > *It would be a good idea for git submodule to work with foreign VCS,
 > through Daniel's patches.


But that would not only apply to submodules, but rather all repositories,
 to the point that "git submodule" does not need any change.

Fair enough. There's plenty of other work to be done!

 > I appreciate the guidance, it's helping me to see that some of this work
 > has already been done, it needs to be finished and pushed into a public
 > release. As an intense user of submodules, what does it do poorly/not do
 > for your needs?


One gripe I have, but which should be rather easy to fix: "git checkout --
 submodule/" does not update the index, last time I checked.  (It correctly
 does not touch the submodule's working directory.)

I'll add it to the list. In terms of general gripes: git submodule add
(or all of git submodule?) handles relative links poorly (see
http://kerneltrap.org/mailarchive/git/2007/12/10/485597). And the
'Gotchas' listed at
http://git.or.cz/gitwiki/GitSubmoduleTutorial#head-a3cba9cbd1e125c0667dfb3b9249100be7f815ad.

 Another one: The most common mistake with submodules is to commit and push
 the superproject, after having committed (but not pushed) in the
 submodule.  Not sure how that could be helped.

Seems like this is on the git submodule wiki 'Gotcha' list, too.
There's a spectrum of options: failing, warning, generating an output
message, etc. I think it is worth working on. What is git's policy on
interrupting users when their actions _could_ be counterproductive to
their intentions? Would hooks on the submodule's commit written by the
user fix this? That's not a built-in solution.

 Further, often it would come in rather handy to be able to say something
 like "git diff $REVISION_AS_COMMITTED_IN_THE_SUPERPROJECT" from within
 the submodule...

That sounds complex, and would break expectations. This would only
work if git in the submodule working directory knows its a submodule.
Is there a way to reference it's super project?

 git submodule summary should output to the pager by default.

Added to the list.

 Oh, and it would not hurt performance on Windows at all if git-submodule
 would be finally made a builtin.

You mean rewriting git-submodule.sh in C? What other impacts might that have?

Thanks,

Phillip Baker

 Ciao,
 Dscho