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

[Rostislav Krasny <rosti.bsd@gmail.com>]

On Wed, Jul 21, 2021 at 10:26 AM Atharva Raykar <raykar.ath@gmail.com> 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.