Jens Lehmann wrote: > Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra: >> 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? > > It's not crippled at all, that is just the way it was from submodule > day one. And no, it isn't always better to relocate it. E.g. when > you want to be able to just tar away work tree and history someplace > else because you don't have (or don't want) an upstream to push to, > you'd be very surprised a "submodule add" moved your .git directory > someplace else effectively nuking the backup of your history and > refs (guess under what circumstances you'll notice that). While I > believe most submodule users would benefit from such a relocation, I > consider the other use cases as valid and we would introduce silent > breakage on them. On the other hand I made all relevant commands > complain loudly about the .git directory in the submodule's work > tree when it matters, so users can do something about it when they > need it and are told so.
I see. Thanks for the explanation. >> Why a new subcommand? Is there a problem if we do the relocation at >> the time of 'add'? Will some user expectation break? > > For me relocation at the time of 'add' would be ok with a new option > (and it might also make sense to have a config option changing the > default for users who want that), but not as the default. Makes sense. This seems trivial to implement: I'll get to work on it soon. > 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 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. -- 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
