Re: [PATCH] submodule: add 'deinit' command
Am 02.12.2012 03:00, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de 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.lehm...@web.de --- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] submodule: add 'deinit' command
Jens Lehmann jens.lehm...@web.de writes: 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. I tend to agree; I suspect that a deinit would be mostly done either to (1) correct mistakes the user made during a recent init and perhaps sync; or (2) tell Git that the user has finished woing with this particular submodule and does not intend to use it for quite a while. For both (1) and (2), I think it would be easier to users if we gave them a clean slate, the same state as the one the user who never had ran init on it would be in. A user in situation (1) is asking for a clean slate, and a user in situation (2) is better served if he does not have to worry about leftover entries in $GIT_DIR/config he has long forgotten from many months ago (during which time the way the project uses the particular submodule may well have changed) giving non-standard experience different from what other project participants would get. If there were a sane workflow where it makes sense to frequently run deinit followed by some operation followed by init, it may be helpful to have an option to keep the other customization. And one consideration when implementing that deinit --keep-customization option might be to introduce the submodule.$name.activated boolean; that way, the operation can keep the customized upstream URL. In any case, it needs to be shown that such a workflow exists in the first place to justify deinit --keep-customization. I think the default should be to remove the submodule.$name section. -- 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
Re: [PATCH] submodule: add 'deinit' command
Jens Lehmann jens.lehm...@web.de 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.lehm...@web.de --- 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? Am 01.12.2012 16:56, schrieb Jens Lehmann: Am 01.12.2012 00:52, schrieb Phil Hord: If I never 'submodule init' a submodule, it does not get visited by 'git submodule foreach', among others. I think some people use this behavior explicitly. On the other hand, I've also notice that a submodule which I have removed does not get de-inited later one. It causes my 'git submodule foreach' to emit errors. :-( I'm currently hacking on git submodule deinit which removes the 'url' setting from git/config. This should do the trick for you, right? And here we go ... Documentation/git-rm.txt| 4 Documentation/git-submodule.txt | 11 + git-submodule.sh| 50 - t/t7400-submodule-basic.sh | 11 + 4 files changed, 75 insertions(+), 1 deletion(-) diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index 262436b..ec42bf5 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree. Ignored files are deemed expendable and won't stop a submodule's work tree from being removed. +If you only want to remove the local checkout of a submodule from your +work tree without committing that use `git submodule deinit` instead +(see linkgit:git-submodule[1]). + EXAMPLES `git rm Documentation/\*.txt`:: diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index b1de3ba..fba77f6 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -13,6 +13,7 @@ SYNOPSIS [--reference repository] [--] repository [path] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...] 'git submodule' [--quiet] init [--] [path...] +'git submodule' [--quiet] deinit [--] [path...] 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n] @@ -134,6 +135,16 @@ init:: the explicit 'init' step if you do not intend to customize any submodule locations. +deinit:: + Unregister the submodules, i.e. remove the `submodule.$name.url` + setting from .git/config. Further calls to `git submodule update`, + `git submodule foreach` and `git submodule sync` will skip any + unregistered submodules until they are initialized again, so use + this command if you don't want to have a local checkout of the + submodule in your work tree anymore. If you really want to remove + a submodule from the repository and commit that use + linkgit:git-rm[1] instead. + update:: Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. diff --git a/git-submodule.sh b/git-submodule.sh index 2365149..4059a2e 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -8,6 +8,7 @@ dashless=$(basename $0 | sed -e 's/-/ /') USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference repository] [--] repository [path] or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
