Am 02.12.2012 03:00, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> 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 url >> setting 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. >> >> Add tests and link the man pages of "git submodule deinit" and "git rm" to >> assist the user in deciding whether removing or unregistering the submodule >> is the right thing to do for him. >> >> Signed-off-by: Jens Lehmann <Jens.Lehmann@xxxxxx> >> --- > > I fully agree with your analysis on the reason why the "url" element > is special and has to be copied to $GIT_DIR/config, but when you > deinit (or uninit) a submodule to say you are no longer interested > in it and do not want it populated in the context of the > superproject, I am not sure if removing only submodule.$name.url (so > that when you later decide to "init" it again, you will keep the > values for submodule.$name.update and other things from the previous > life) is the sane thing to do, or it is better to remove > submodule.$name.* altogether as if an earlier "init" has never > happened. Would it be worth analyzing the pros-and-cons here? Sure. I was worried about throwing away other settings the user might have set in the submodule.$name section and the first reflex was to protect them. But thinking about that again I noticed we are already throwing away a possibly user customized "url" setting, so we already remove a possibly customized setting. Maybe the principle of least surprise is better followed when we nuke the whole section, as it might surprise the user more to have a setting resurrected he customized in the last life cycle of the submodule than seeing that after an deinit followed by an init all former customizations are consistently gone. So I tend to think now that removing the whole section would be the better solution here. Opinions by other submodule users? -- 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