Why, in some situation does "git checkout origin/branch" result in "detached at <SHA>" instead of "detached at origin/master"? -

i'm working on large enough repo, multiple submodules. ensure we're in correct state during ci process, init submodules,

$ git submodule init $ git submodule sync $ git submodule update --force 

which prints out like,

synchronizing submodule url 'android/public' synchronizing submodule url 'ios/public' ...  submodule path 'android/public': checked out 'asdf1234' submodule path 'ios/public': checked out 'bsdf2345' 

if go through , check out few different branches, if run

$ platform in android ios $ $   (cd $platform/public; git fetch --all; git checkout origin/master) $ done 

and check folders git branch, (head detached @ origin/master).

if redo submodule initialisation @ top, , run

$ platform in android ios $ $   (cd $platform/public; git fetch --all; git reset --hard origin/master; git checkout origin/master) $ done 

and check these again git branch, show (head detached @ <some sha>).

this kind of legacy procedure in our ci, changed, i'd still know why running git checkout origin/master wouldn't always result in git branch displaying head detached @ origin/master.

the "detached at" string merely attempt informative. older versions of git use only hash id , ever see "detached @ <hash>".

newer versions of git attempt remember items git checkout command did detaching, , "detached @ something_more_informative" if can. here see detached @ origin/master. lose detail in various cases, including if move current commit (by writing new commit ids head, e.g., using git checkout again or making new commits). in case newer versions of git begin "detached from" instead of "detached at", , hang on information, whether it's hash id or name. while newer git versions attempt this, have minor bugs , fail distinguish "detached from" , "detached at" properly.

in this particular case—although it's git-version-dependent—chances reason last example process results in "detached @ hash" git reset --hard origin/master moves given commit id, clobbering old retained information, , git checkout origin/master sees not move, i.e., you're at id, not update retained hash-or-name.

if that's case, replacing git reset --hard origin/master git reset --hard, subsequent git checkout does (usually) move, change retained information name.