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
I think this is needed because it makes little sense to having an
attached HEAD and "git submodule update" does nothing.
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