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

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

Francesco Pretto <ceztko@gmail.com> writes:

Show 14 quoted lines

>>> >  - In which situations does the developer or maintainer switch between
>>> >    your attached/detached mode?
>>>
>>> The developer/maintainer does so optionally and voluntarily and it
>>> effects only its private working tree.
>>
>> This does not answer my question. I would like to find out the reason
>> why one would do the switch.
>
> The developer does it voluntarily, at his responsibility, because he
> may decide to partecipate more actively to the development of the
> submodule and still want to use a simple "git submodule update" to
> updates his submodules, overriding its configuration as it can be done
> for other properties like, for example, "branch".

It is still unclear to me why we need attached/detached mode for that. The developer may want to do an exploratory development, whose result is unknown to deserve to be committed on the specified branch at the beginning, and choose to build on a detached HEAD, which is a perfectly normal thing to do. But the standard way to do so, whether the developer is working in the top-level superproject or in a submodule, would be to just do:

	cd $there && git checkout HEAD^0

or use whatever commit the state to be detached is at instead of "HEAD" in the above example, no?