{"thread":{"id":"28010","subject":"git clone does not checkout active branch","startedAt":"2011-08-03T16:56:43Z","lastAt":"2011-08-03T20:04:38Z","messageCount":2,"participants":["Udo","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"172781","messageId":"loom.20110803T185528-8@post.gmane.org","threadId":"28010","inReplyTo":null,"subject":"git clone does not checkout active branch","fromName":"Udo","fromEmail":"u.offermann@gmail.com","sentAt":"2011-08-03T16:56:43Z","receivedAt":"2011-08-03T16:56:43Z","isPatch":false,"sender":{"key":"u.offermann@gmail.com","avatar":null},"body":"I have a remote bare repository with two branches 'master' and 'testing', where\nHEAD refers to 'testing'. When cloning this repository git checks out 'master',\nif 'master' and 'testing' are on the same revision (i.e. HEAD == testing ==\nmaster). Only if 'testing' is one (or more) commit(s) behind or ahead, git clone\nchecks out the 'testing' branch on the local side. I tried this with git 1.7.5\non Mac OS X (10.6.8).\n\nAddendum: I just tried the same with a non-bare repository:\n\nmkdir A\ncd A\ngit init\ntouch a\ngit add a\ngit commit -m \"init repo A with a\"\ngit checkout -b testing\n\nnow back in the root dir:\n\ncd ..\ngit clone A B\ncd B\ngit branch -v -a\n* master                 28f599b init A\n  remotes/origin/HEAD    -> origin/master\n  remotes/origin/master  28f599b init A\n  remotes/origin/testing 28f599b init A\n\nit's 'master'! Back to repo A (we are still in branch 'testing'):\n\ncd ../A\ntouch b\ngit add b\ngit commit -m \"add b in branch testing\"\n\nnow 'testing' is one commit ahead 'master'. Now let's clone A again:\n\ncd ..\ngit clone A C\ncd C\ngit branch -a -v\n* testing                23bca39 add b in branch testing\n  remotes/origin/HEAD    -> origin/testing\n  remotes/origin/master  28f599b init A\n  remotes/origin/testing 23bca39 add b in branch testing\n\nYou can re-verify this weird behavior by going back to A, checkout 'master' and\nmerge it with 'testing' (so that all branches have the same head). Now clone A\ninto D and D will be checked out on master!\n"},{"id":"172802","messageId":"20110803200438.GC23848@sigill.intra.peff.net","threadId":"28010","inReplyTo":"loom.20110803T185528-8@post.gmane.org","subject":"Re: git clone does not checkout active branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-03T20:04:38Z","receivedAt":"2011-08-03T20:04:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 03, 2011 at 04:56:43PM +0000, Udo wrote:\n\n> I have a remote bare repository with two branches 'master' and 'testing', where\n> HEAD refers to 'testing'. When cloning this repository git checks out 'master',\n> if 'master' and 'testing' are on the same revision (i.e. HEAD == testing ==\n> master). Only if 'testing' is one (or more) commit(s) behind or ahead, git clone\n> checks out the 'testing' branch on the local side. I tried this with git 1.7.5\n> on Mac OS X (10.6.8).\n\nYes, this is a known issue.\n\nThe git protocol just sends the list of refs and the objects they point\nto. So the local clone is forced to guess which ref HEAD is pointing to.\nE.g., with something like:\n\n  28f599b... HEAD\n  1234abc... refs/heads/master\n  28f599b... refs/heads/testing\n\nit can see that HEAD is probably \"testing\". But if it sees:\n\n  28f599b... HEAD\n  28f599b... refs/heads/master\n  28f599b... refs/heads/testing\n\nthen it has to pick one arbitrarily. Our current heuristic is to prefer\n\"master\" over others, and otherwise pick first alphabetically. So it's\nat least deterministic, but as you noticed, it's not always right.\n\nThe real solution to this would be to extend the git protocol to convey\nsymbolic ref information (and then wait for both client and server to be\nupgraded). Some patches have been floated in the past, but nothing came\nof it[1]. Maybe it's time to resurrect them.\n\nAs a workaround, you can use \"git clone -b testing ...\" if you know\nahead of time that \"testing\" is what you want.\n\n-Peff\n\n[1] See:\n\n    http://thread.gmane.org/gmane.comp.version-control.git/102039\n\nand also:\n\n    http://article.gmane.org/gmane.comp.version-control.git/113567\n"}]}