Re: Why do submodules detach HEAD? (was Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules ...)

[Atharva Raykar <raykar.ath@gmail.com>]

Rostislav Krasny <rosti.bsd@gmail.com> writes:

> On Wed, Jul 21, 2021 at 10:26 AM Atharva Raykar <raykar.ath@gmail.com> wrote:
>> [...]
>> We want to have idempotence, ie, for a particular revision that is
>> registered by our parent project, we want 'update' to give the same
>> outcome every time, and not be dependent on whatever the state of the
>> branch is. This way we ensure that for a particular commit in the
>> parent project, the submodules will be in the same state for every
>> system in the world, after an 'update' is run.
>
> All this is ok, but there could be other uses of sub-modules. Why not
> to make this behavior configurable?
>
> As a developer I may want to make new commits on those sub-modules and
> always work with latest versions of their particular branches. In the
> detached HEAD mode this is much harder to be done and also an error
> prone operation. Commits that are done in the detached HEAD state may
> easily be lost. [...]

Have you tried running 'submodule update --merge' or
'submodule update --rebase'? Those modes will not detach your
submodule's HEAD.

The Pro Git book has a section that explains a workflow that sounds
similar to what you describe:

https://git-scm.com/book/en/v2/Git-Tools-Submodules

Around halfway down the page, look for the heading "Working on a
Submodule". Does that fit your use case?

> [...] Google is full of questions about how this could be done, i.e. there
> is an essential demand of such a new behavior.

It would be nice if you can share a specific link that captures the
demand you are talking about. When I Googled about this behaviour, I got
a range of different kinds of results, without a clearly voiced demand.
If you can show an example that best represents this demand, the Git
developers here may be able to address it better.