On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote: > "W. Trevor King" <wk...@tremily.us> 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.
This is what I'm doing now: $ git submodule add -b <branch> <repo> <path> $ git config --file .gitmodules submodule.<path>.branch <branch> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With my second patch (Phil's config export), that becomes $ git submodule add -b <branch> <repo> <path> $ git config --file .gitmodules submodule.<path>.branch <branch> $ git submodule foreach 'git checkout $submodule_branch && git pull' With my first patch, that becomes $ git submodule add -rb <branch> <repo> <path> $ git submodule foreach 'git checkout $submodule_branch && git pull' This seems pretty useful to me, but I'm still using submodule.<name>.branch explicitly as a user, and Git is not interpreting the option directly. Users are free to store whatever they like in that option, and use it however they wish: $ git submodule foreach 'do-crazy-stuff.sh $submodule_branch' If we need a semantic interpretation to justify -r/--record, everyone that's chimed in so far has agreed on the same interpretation. I wouldn't be averse to $ git submodule add -rb <branch> <repo> <path> $ git submodule pull-branch which makes the foreach pull logic internal. However, there has been a reasonable amount of resistance to this workflow in the past, so I thought that a patch series that avoided a semantic interpretation would be more acceptable. If neither an agnostic -r/--record or a semantic pull-branch command are acceptable, I suppose we'll have to drop my first and third patches and only keep the second. Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -- 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
