From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: Re: checkout -b remotes/origin/<branch> should not work
Date: Sun, 14 May 2017 17:00:36 +0900 [thread overview]
Message-ID: <xmqqefvr50m3.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: 20170514040048.evwtngo6bixtrput@sigill.intra.peff.net
Jeff King <peff@peff.net> writes:
> I think this problem extends beyond "remotes/". The worst is:
>
> git checkout -b HEAD
>
> but there are many confusing variants:
>
> git checkout -b refs/heads/foo
> git checkout -b tags/v1.0
>
> etc. Those are all perfectly legal names, but almost certainly not what
> the user intended. I think the plumbing should continue to allow them,
> but I wouldn't object to some common-sense think-o protections in the
> "checkout -b" plumbing (especially if it could be disabled for power
> users).
Yup. I suspect that the last one has uses (for those who may want
to build on v1.0 tag it is conceivable that a local branch they use
for it is named like so), but I agree that anything that begins with
refs/* is not something any sane person would want to use.
sanity.branchname configuration or something that tells "checkout"
and "branch" Porcelain commands to barf on an attempt to create such
refnames does not sound too bad, and making it on by default may not
even be a bad idea. But that leads me to say it may not even need
to be a configurable thing (people who DO want funny names can
already and still use the plumbing).
In any case, no command after such a change should forbid checking
out such a funny-named branch if it already exists. We should
complain only on (an attempted) creation.
prev parent reply other threads:[~2017-05-14 8:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-14 3:52 checkout -b remotes/origin/<branch> should not work Stefan Beller
2017-05-14 4:00 ` Jeff King
2017-05-14 8:00 ` Junio C Hamano [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=xmqqefvr50m3.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.