From: Jeff King <peff@peff.net>
To: Tony Sales <vinux.development@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: I want to report a bug/anomaly in Git
Date: Wed, 12 Jan 2011 13:35:56 -0500 [thread overview]
Message-ID: <20110112183556.GD31747@sigill.intra.peff.net> (raw)
In-Reply-To: <AANLkTimt+U3oo4FaywUr86ArG8d29yWAeVYhpRkBYa_K@mail.gmail.com>
On Tue, Jan 11, 2011 at 10:22:29PM +0000, Tony Sales wrote:
> The bug is that if you happen to create a new remote branch which
> shares it's name with an existing directory in the top level of the
> git repository, git then seems to get confused and the: git checkout
> <branch> - command doesn't switch to that branch or turn tracking on
> (and seems to think it was created from origin/<branch> rather than
> from refs/remotes/origin/<branch>), which it does if the branch
> doesn't share a name with an existing top level directory. This can be
> rectified by running: git checkout --track -b debian origin/debian
I don't think this is a bug so much as a confusing application of too
much DWIMmery in git-checkout. "git checkout foo" can mean several
things:
1. If it's a branch name, then switch to that branch.
2. Otherwise, if it's a tag name, switch to a detached HEAD at that
tag.
3. Otherwise, if it's a file known to git, then checkout its content
in the index into the working tree.
4. Otherwise, if there is a remote branch that matches
refs/remotes/*/foo, create a new branch "foo" that tracks it.
So the problem is that you expect behavior (4), but behavior (3) is
getting in the way.
I assume it was written this way because (4) came much later, and
therefore came last so as not to break existing behavior for the other
cases. Conceptually, though, I think it makes more sense for it to come
(3) (i.e., to keep all of the "checking out a ref" behavior together).
And one can disambiguate the path-mode already by doing:
git checkout -- debian
-Peff
prev parent reply other threads:[~2011-01-12 18:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 22:22 I want to report a bug/anomaly in Git Tony Sales
2011-01-12 18:35 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110112183556.GD31747@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=vinux.development@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).