Am 25.10.2012 02:53, schrieb W. Trevor King: > On Wed, Oct 24, 2012 at 09:15:32PM +0200, Jens Lehmann wrote: >> I still fail to see what adding that functionality to the submodule >> command buys us (unless we also add code which really uses the branch >> setting). What's wrong with doing a simple: >> >> git config -f .gitmodules submodule.<path>.branch <record_branch> >> >> on the command line when you want to use the branch setting for your >> own purposes? You could easily wrap that into a helper script, no? > > Sure. But why maintain my own helper script if I can edit > git-submodules.sh? It seems like a number of people are using this > config option, and they generally store the same name in it that they > use to create the submodule. This way I can save them time too. But people are already using the "branch" setting in *different* ways: Am 23.10.2012 22:55, schrieb W. Trevor King: > As Phil pointed out, doing anything with this variable is ambiguous: > > On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote: >> Some projects now use the 'branch' config value to record the tracking >> branch for the submodule. Some ascribe different meaning to the >> configuration if the value is given vs. undefined. For example, see >> the Gerrit submodule-subscription mechanism. This change will cause >> those workflows to behave differently than they do now. I don't have a problem with the amount or complexity of the code being added, But by adding that option we may be giving the impression that it is officially sanctioned, or that it will be kept up to date by further submodule commands. I added Shawn to the CC, maybe he can comment on how the "branch" setting is used in Gerrit and what he thinks about adding code to set that with "git submodule add -r <branch> ..." to core git. -- 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