On Wed, Aug 17, 2011 at 11:41 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Conrad Irwin <conrad.irwin@xxxxxxxxx> 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 <foo> <current-branch>
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html