Re: [PATCH 2/2] Introduce git submodule attached update

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 7, 2014, 19:07 UTC
Message-ID: <xmqqy52rd30b.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CALas-ihHD_eJOXLUrhCVZjidQDmrCN=QpdfMKoN1i9A7FAo3RQ@mail.gmail.com>

Francesco Pretto <ceztko@gmail.com> writes:

Show 11 quoted lines

> 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?