> > *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 > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
