2014/1/7 Junio C Hamano <gits...@pobox.com>: >> Unless you decide to go with the proposed approach of Trevor, where >> "submodule.<name>.branch" set means attached (if it's not changed: >> this thread is quite hard to follow...). To this end, Junio could sync >> with more "long-timers" (Heiko?) submodule users/devs to understand if >> this breaks too much or not. > > It is not immediately obvious to me why anybody who specifies the > submodule.*.branch variable to say "I want _that_ branch" not to > want to be on that branch but in a detached state, so from that > perspective, submodule.*.attach feels superfluous. >
Junio, for what it concerns me I fully support this patch as, IMO, it makes cleaner the role of the property "submodule.<name>.branch". Because with my original proposal I decided to go non-breaking Heiko and Jens could also take position on this because this patch will represent a small behavior break. Also, and important feature should be added together with this patch: a way to go "--remote" by default on an attached HEAD. This can be done at least in two ways: - explicit, non breaking way: add a "submodule.<name>.remote" property. When set to "true" it implies "--remote" when doing "git submodule update", both on attached and detached HEAD; - implicit, breaking way: assume "--remote" when doing "git submodule update" on an attached HEAD. I am quite sure this will break a couple of submodule tests (I already tried it), probably for marginal reasons. I think this is needed because it makes little sense to having an attached HEAD and "git submodule update" does nothing. Thank you, Francesco -- 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
