Am 26.03.2013 08:57, schrieb Ramkumar Ramachandra: > Jens Lehmann wrote: >> And leaving aside 'add', there are tons of submodules out there >> which were cloned with older Git who have their .git directory >> inside the work tree. So a new subcommand (or at least a helper >> script in contrib) to relocate the .git directory would really help >> here to migrate these legacy submodules without users having to >> worry about data loss. > > The question is: after using a "non-relocated submodule" for some > time, will the user suddenly decide to make it a "relocated submodule" > one day? I think quite some users - and definitely myself - will do that as soon as the full recursive checkout materialized, as that allows to remove submodules without any directory remaining and even to replace a submodule with a directory containing other files. And even with current Git you already get a clean work tree when using "git rm" or "git submodule deinit" (in current master) on a submodule iff it has its .git directory stored in the .git directory of the superproject. It is definitely not a Must Have right now, but I expect it to be that in the near future. >>> 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. >> >> Ah, now I get it, I was confused by your reference to 'git submodule >> add <repository> <path>'. I have to admit I still don't understand >> the use case you have for adding a submodule without staging it, but >> maybe it is just too late here. > > I usually reset after running 'git submodule add', because I rarely > commit the added submodule immediately after adding it. I'm not sure many submodule users do the same, but even then the normal ways of unstaging the submodule and .gitmodules should be sufficient here, no? I'd rather avoid adding a new command to git submodule for that. -- 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