This repository has been archived by the owner. It is now read-only.

"git checkout head" results in detached HEAD state #114

Closed
Saaman opened this Issue Apr 24, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@Saaman

Saaman commented Apr 24, 2013

I created a simple git repository, and run this :

$ git checkout head
Note: checking out 'head'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 99d2060... My third commit

$ git reflog
99d2060 HEAD@{0}: checkout: moving from master to head

It seems that msysgit is able to match HEAD as it points at the correct commit My third commit, but what I don't understand is that it switches to detached HEAD state. I don't know if it's a bug or some unexpected corner case...

It is only happening on Windows, certainly because of the case-insensitive file system. This can't be reproduced on Linux.

I first ask about this on stackoverflow, but without any luck.

@sschuberth

This comment has been minimized.

Show comment
Hide comment
@sschuberth

sschuberth May 3, 2013

Member

@svnpenn I think otherwise. I believe @Saaman is well aware that you should usually write HEAD in upper case. However, if you don't for some reason, git checkout head should fail with error: pathspec 'head' did not match any file(s) known to git. (if you don't have a branch that's actually called head), just like it does on Linux. It should also not go into detached HEAD state.

Even when considering the case-insensitive of the Windows file system it's somewhat strange that git checkout head doesn't simply do the same as git checkout HEAD, i.e. stay on the current branch instead of going into detached HEAD state. Seems like some Git code paths don't handle this correctly even with core.ignorecase set to true.

Member

sschuberth commented May 3, 2013

@svnpenn I think otherwise. I believe @Saaman is well aware that you should usually write HEAD in upper case. However, if you don't for some reason, git checkout head should fail with error: pathspec 'head' did not match any file(s) known to git. (if you don't have a branch that's actually called head), just like it does on Linux. It should also not go into detached HEAD state.

Even when considering the case-insensitive of the Windows file system it's somewhat strange that git checkout head doesn't simply do the same as git checkout HEAD, i.e. stay on the current branch instead of going into detached HEAD state. Seems like some Git code paths don't handle this correctly even with core.ignorecase set to true.

@Saaman

This comment has been minimized.

Show comment
Hide comment
@Saaman

Saaman May 3, 2013

This is exactly what I meant @sschuberth !

FYI, I cared about this corner case when implementing reflog on checkout in LibGit2Sharp.

Saaman commented May 3, 2013

This is exactly what I meant @sschuberth !

FYI, I cared about this corner case when implementing reflog on checkout in LibGit2Sharp.

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Dec 30, 2013

Member

I guess there is nobody interested enough in this issue to try to come up with a fix. If I'm wrong, please feel free to open a pull request.

Member

dscho commented Dec 30, 2013

I guess there is nobody interested enough in this issue to try to come up with a fix. If I'm wrong, please feel free to open a pull request.

@dscho dscho closed this Dec 30, 2013

@camsteffen camsteffen referenced this issue in git-for-windows/git Aug 14, 2016

Open

"git checkout head" inconsistent behavior #852

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.