Am 12.12.2012 16:08, schrieb Michael J Gruber: > Jens Lehmann venit, vidit, dixit 04.12.2012 22:48: >> With "git submodule init" the user is able to tell git he cares about one >> or more submodules and wants to have it populated on the next call to "git >> submodule update". But currently there is no easy way he could tell git he >> does not care about a submodule anymore and wants to get rid of his local >> work tree (except he knows a lot about submodule internals and removes the >> "submodule.$name.url" setting from .git/config himself). >> >> Help those users by providing a 'deinit' command. This removes the whole >> submodule.<name> section from .git/config either for the given >> submodule(s) or for all those which have been initialized if none were >> given. Complain only when for a submodule given on the command line the >> url setting can't be found in .git/config. > > Whoaaa, so why not have "git rm" remove everything unless I specify a > file to be removed? Because "git add" doesn't add any file in that case either? > I know I'm exaggerating a bit, but defaulting to "--all" for a > destructive operation seems to be a bit harsh, especially when the > command is targeted at "those" users that you mention. All other submodule commands (except add, which only operates on a single submodule to be) iterate over all submodules if none were explicitly given on the command line. So I made deinit just behave like all the others - and especially init - do. But if people really are surprised by being consistent here I won't argue against adding such a "--all" option, but currently I'm not convinced it is worth it. Especially as I suspect the number of submodule users having customized those in .git/config is not that high ... -- 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