Re: Q: submodules and detached HEAD

[Junio C Hamano <gitster@pobox.com>]

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

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

> 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?


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