Re: Q: submodules and detached HEAD

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 27, 2020, 17:13 UTC
Message-ID: <xmqqsgiweyxs.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <5E578F2A020000A1000373EF@gwsmtp.uni-regensburg.de>

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:

Show 9 quoted lines

> I'm rather new to submodules, and I have a question on something I don't understand (git-2.12.3 from SLES12):
> I had checked out tag v0.0.1 of my submodule.
> When checking the status, I see:
>
> iptables> git status
> HEAD detached at v0.0.1
> nothing to commit, working tree clean
> iptables> git checkout v0.0.1
> HEAD is now at b23fbdc... .version: 0.0.1

I do not see anything special about "submodule" in the above. Assuming that v0.0.1 is a tag (i.e. refs/tags/v0.0.1 points at a commit whose object name is b23fbdc...), what we see in the above is quite expected.

Show 9 quoted lines

> iptables> git checkout v0.0.2
> Previous HEAD position was b23fbdc... .version: 0.0.1
> HEAD is now at 5af0df5... v0.0.2: Fix issue with "xtables lock"
> /iptables> git status
> HEAD detached at v0.0.2
> nothing to commit, working tree clean
> iptables> git branch
> * (HEAD detached at v0.0.2)
>   master

So is the above, under the assumption that v0.0.2 is a tag and not a branch. When you give a commit to "git checkout <what-to-checkout>" instead of giving it a branch name, the HEAD points directly at the given commit and the state is called "detached HEAD".

I do not quite get what the question is. What was the end-user expectation and how is the actual behaviour different from it?

Show 8 quoted lines

> git reflog says:
> 5af0df5 HEAD@{0}: checkout: moving from b23fbdc0e18e570a4d9ec4cb8826afc82e2e0b64 to v0.0.2
> b23fbdc HEAD@{1}: checkout: moving from ec7dd70b59e039b49bb478a3134b713a2b0a279c to v0.0.1
> ec7dd70 HEAD@{2}: checkout: moving from master to v0.0
>
> Config submodule.iptables.branch is not set.
>
> Who can explain?

Not me, especially without knowing what to explain. Everything I saw so far is expected.