2014/1/7 Junio C Hamano <gits...@pobox.com>:
> Francesco Pretto <cez...@gmail.com> writes:
>> My bottom line:
>> - For what I understand, detached HEAD it's a way to say "hey, you
>> have to stay on this commit. Also don't even think you can push to the
>> upstream branch". This sometimes can't be spurious, as in the use case
>> I wrote above: access control on the remote repositories should be
>> enough. I think maintainers should have the option to make developers
>> to clone a repository starting with an attached HEAD on the branch
>> suggested in submodule.$name.branch;
>> - "git submodule update" is missing a property to do automatically
>> "--remote". I think in the use case I wrote it's really handy to have
>> a "git submodule update" to act like this.
> The short version I read in the message is that your workflow, in
> which partipants want to work on a branch, gets frustrating with the
> current system only because the default update/initial cloning
> detaches HEAD and will stay in that state until the user gets out of
> the detached state manually. Once that initial detachment is fixed,
> there is no more major issue, as update will stay on that branch.
> Am I reading you correctly?
Yep, you got it correctly.
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