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

Rostislav Krasny [off-list ref] writes:

On Wed, Jul 21, 2021 at 10:26 AM Atharva Raykar [off-list ref] wrote:

quoted

[...]
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.