From: Conrad Irwin Date: Fri, 19 Aug 2011 18:14:11 GMT Subject: Re: [PATCH] Disallow creating ambiguous branch names by default Message-ID: In-Reply-To: <7vhb5fev8a.fsf@alter.siamese.dyndns.org> On Wed, Aug 17, 2011 at 11:41 AM, Junio C Hamano wrote: > Conrad Irwin writes: > >> Before this change, it was comparatively easy to create a confusingly > > Drop everything before the ", ". > >> named branch (like "origin/master" or "tag.1"). The former case is >> particularly biting to newcomers, who suddenly find themselves needing >> to handle nuances of the refs namespaces. > > If you start forbidding certain names, newcomers will need to be exposed > the same nuances to understand why what they wanted to do is not allowed, > so that is not an argument. > > My preferences (take them as "the ground rules" if you want) are: > >  - We don't disallow what we have long allowed, without a good reason; >  - We make sure new people will get a warning with useful advice. > > I would be happy to see the end result that warns when the end user > creates a branch (or a tag) that is ambiguous _when_ it is created (not > "much later, when we noticed there are ambiguous refs"), and offers an > advice message to use "branch -m" to rename it away (control the message > with a new "advice.*" configuration and unless explicitly declined with > it, always give the advice). > In the process of changing things around to do this, I noticed that git checkout -M surprisingly works, and does confusing things, in that you will get a: $ git rev-parse HEAD@{1} warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700 Presumably this is the reason that git branch -f forbids you from changing the current branch? If so is this a reasonable case where the current behaviour should be forbidden (with the same error message "fatal: Cannot force update the current branch.") — or should I just make it output a warning? Conrad