Hi, On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote: > "W. Trevor King" <wking@xxxxxxxxxx> writes: > > > By remaining agnostic on the variable usage, this patch makes > > submodule setup more convenient for all parties. > > I personally do not think "remaining agnostic on the usage" is a > good thing, at least for any option to commands at the higher level > on the stack, such as "git submodule". I am afraid that giving an > easier way to set up a variable with undefined semantics may make > setup more confusing for all parties. One party gives one specific > meaning to the field, while another party uses it for something > slightly different. > > I would not object to "git config submodule.$name.branch $value", on > the other hand. "git config" can be used to set a piece of data > that has specific meaning, but as a low-level tool, it is not > _limited_ to variables that have defined meaning. I think we should agree on a behavior for this option and implement it the same time when add learns about it. When we were discussing floating submodules as an important option for the gerrit people I already started to implement a proof of concept. Please have a look here: https://github.com/hvoigt/git/commits/hv/floating_submodules AFAIK this does not yet implement the same behaviour the gerrit tools offer for this option. The main reason behind that was because I do not know the typical workflow behind such an option. So I am open to changes. Maybe you can use or base your work on this implementation for submodule update. Without submodule update using this option I think it would be better to implement this option in the tool you are using instead of submodule add. Everything else feels incomplete to me. Cheers Heiko -- 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