Jens Lehmann wrote: > Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra: >> In my opinion, the 'git submodule add <path>' form is broken, because >> it doesn't relocate the object store of the submodule repository (a >> bug that we need to fix?). > > I don't think it is broken. Leaving the .git directory inside the > submodule makes perfect sense for some users (e.g. those which never > intend to push their submodule somewhere else) and doesn't do any > harm unless you want to remove it again in the future (or need to go > back to an older commit where the submodule directory would be in > the way). We have to think very hard before making such changes to > behavior quite some people may rely on, even though I agree some use > cases would profit from it and I think we would do it differently if > we could start over again. Doesn't that sound horribly crippled to you? Is there any advantage to leaving the .git directory inside the submodule? Isn't it always better to relocate it? > What I think we need rather soonish is "git submodule to-gitfile", > which would help your case too. We should then hint that in those > cases where we refuse to remove a submodule when using "git rm" or > "git submodule deinit" (or the "git mv" for submodules I'm currently > preparing). Why a new subcommand? Is there a problem if we do the relocation at the time of 'add'? Will some user expectation break? >> I always use the 'git submodule add >> <repository> <path>' form, which puts the object store of the >> submodule repository in .git/modules of the parent repository. This >> form is nothing like 'git add', but more like a 'git clone': arguably, >> 'submodule clone' is a better name for it. > > Hmm, it does a clone first and then adds the submodule and the change > to .gitmodules, so I still believe "add" is the correct term for it. > So I really like the color the shed currently has ;-) I meant a variant of add that would clone, but not stage. I was arguing for a new subcommand so that I don't have to touch 'submodule add', not for a rename. >> Maybe the WTF "You need to run this command from the toplevel of the >> working tree" needs to be fixed first? I think it's a matter of a >> simple pushd, popd before the operation and building the correct >> relative path. > > I won't object such a change (even though I suspect it'll turn out > more complicated than that). I'll have to investigate. >> I'm not sure how it'll work with nested submodules >> though. Then again, I think nested submodules are Wrong; submodules >> are probably not the right tool for the job. > > How did you come to that conclusion? Nested submodules make perfect > sense and most people agree that in hindsight --recursive should have > been the default, but again we can't simply change that now. Okay, I'll do it step-by-step now, with a live example: 1. git clone gh:artagnon/dotfiles, a repository with submodules. 2. git submodule update --init .elisp/auto-complete, a repository that contains submodules. 3. .elisp/auto-complete/.gitmodules lists the submodules (lib/fuzzy, lib/ert, and lib/popup). Let's try to initialize them from that directory ... No! go back to toplevel. 4. Fine. Where are those submodules? git submodule status doesn't list them. 5. Okay, let's join the paths by hand and try anyway: git submodule update --init .elisp/auto-complete/lib/fuzzy. Did you forget to 'git add'? Fantastic. 6. How am I supposed to initialize the darn submodules?! 7. git submodule update --init --recursive .elisp/auto-complete is the ONLY way (is this even documented anywhere?). But I just wanted to initialize one, not all three! 8. Okay, now I want to execute a 'git submodule foreach' on just those three submodules. Seems impossible. Fine, I'll do it myself: for i in "lib/ert lib/fuzzy lib/popup"; do cd $i; git checkout master; git reset --hard origin/master; cd ../..; done 9. Whew. git status. Changes in auto-complete. git diff. "Submodule .elisp/auto-complete contains modified content". I'm not allowed to see what changed now? 10. git checkout master; git reset --hard origin/master in auto-complete. git status. How do I stage the changes in just auto-complete, and not in auto-complete's submodules? What is going on, seriously? This is just two levels of nesting: with more levels of nesting, things only get worse. >>>> Now, for the implementation. Do we have existing infrastructure to >>>> stage a hunk non-interactively? (The ability to select a hunk to >>>> stage/ unstage programmatically). If not, it might be quite a >>>> non-trivial thing to write. > [...] > Not that I know of. Damn. Then, it's certainly not worth the effort. Atleast not now, when there are bigger problems. -- 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