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

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

The default mode for the update command is to checkout to the
revision that the parent project expects the submodule to be in, ie,
it checks out to the commit hash directly, and detaches the HEAD.

Why not checkout to a branch? This is because branches may change
which commits they point to.

For example, if you had a submodule 'foo'. I go into the 'foo'
folder and amend the last commit.

Now if I run 'submodule update' in the parent repository. If it had
checked out to the branch instead of the revision, I would be on a
different commit in 'foo' than the one that was registered by the
parent repo!

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. Google is full of questions about how this could be
done, i.e. there is an essential demand of such a new behavior.