{"thread":{"id":"26263","subject":"I want to report a bug/anomaly in Git","startedAt":"2011-01-11T22:22:29Z","lastAt":"2011-01-12T18:35:56Z","messageCount":2,"participants":["Tony Sales","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159388","messageId":"AANLkTimt+U3oo4FaywUr86ArG8d29yWAeVYhpRkBYa_K@mail.gmail.com","threadId":"26263","inReplyTo":null,"subject":"I want to report a bug/anomaly in Git","fromName":"Tony Sales","fromEmail":"vinux.development@gmail.com","sentAt":"2011-01-11T22:22:29Z","receivedAt":"2011-01-11T22:22:29Z","isPatch":false,"sender":{"key":"vinux.development@gmail.com","avatar":null},"body":"Hi, how do I report a bug/anomaly in git? I have looked on the git\nwebsite and tried to ask on the git irc on freenode but couldn't post,\neven after requesting a 'voice'. The bug is that if you happen to\ncreate a new remote branch which shares it's name with an existing\ndirectory in the top level of the git repository, git then seems to\nget confused and the: git checkout <branch> - command doesn't switch\nto that branch or turn tracking on (and seems to think it was created\nfrom origin/<branch> rather than from refs/remotes/origin/<branch>),\nwhich it does if the branch doesn't share a name with an existing top\nlevel directory. This can be rectified by running: git checkout\n--track -b debian origin/debian - but this confused me for several\nhours and it was only because I had another repository with the same\nbranch names, but different top level directories where the command\nworked that it finally dawned on me what the problem was. I then\ndeleted the branch and created a new one with a differnt name and\neverything worked as expected.\n\n-- \ndrbongo\n\nDig that crazy beat on the drums: <http://vinux.org.uk>  The best is\ngetting better!\n"},{"id":"159413","messageId":"20110112183556.GD31747@sigill.intra.peff.net","threadId":"26263","inReplyTo":"AANLkTimt+U3oo4FaywUr86ArG8d29yWAeVYhpRkBYa_K@mail.gmail.com","subject":"Re: I want to report a bug/anomaly in Git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-12T18:35:56Z","receivedAt":"2011-01-12T18:35:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 11, 2011 at 10:22:29PM +0000, Tony Sales wrote:\n\n> The bug is that if you happen to create a new remote branch which\n> shares it's name with an existing directory in the top level of the\n> git repository, git then seems to get confused and the: git checkout\n> <branch> - command doesn't switch to that branch or turn tracking on\n> (and seems to think it was created from origin/<branch> rather than\n> from refs/remotes/origin/<branch>), which it does if the branch\n> doesn't share a name with an existing top level directory. This can be\n> rectified by running: git checkout --track -b debian origin/debian\n\nI don't think this is a bug so much as a confusing application of too\nmuch DWIMmery in git-checkout. \"git checkout foo\" can mean several\nthings:\n\n  1. If it's a branch name, then switch to that branch.\n\n  2. Otherwise, if it's a tag name, switch to a detached HEAD at that\n     tag.\n\n  3. Otherwise, if it's a file known to git, then checkout its content\n     in the index into the working tree.\n\n  4. Otherwise, if there is a remote branch that matches\n     refs/remotes/*/foo, create a new branch \"foo\" that tracks it.\n\nSo the problem is that you expect behavior (4), but behavior (3) is\ngetting in the way.\n\nI assume it was written this way because (4) came much later, and\ntherefore came last so as not to break existing behavior for the other\ncases. Conceptually, though, I think it makes more sense for it to come\n(3) (i.e., to keep all of the \"checking out a ref\" behavior together).\nAnd one can disambiguate the path-mode already by doing:\n\n  git checkout -- debian\n\n-Peff\n"}]}