Re: 'git branch' when origin branch with same name exists

[Ryan Lortie <desrt@desrt.ca>]

hi,

On 12-06-19 12:06 PM, Konstantin Khomoutov wrote:
> How bad this state really is?
> The user is free to do
> $ git branch -m gtk-3-4 mygtk-3-4
> at any time after the error was detected.

The user that makes the mistake to type 'git branch' instead of 'git 
checkout' in the first place is unlikely to know about this.

> This would not protect from the obvious case when a branch has been
> created on the remote (by someone else) but has not been fetched yet
> and so the local repo does not know a branch with "conflicting"
> name do exist.

I consider this to be a far less likely case: more of a race condition, 
really, and nothing we can do about it.  This is no reason that we 
should not try to fix the easier case (which is also the far more likely 
case).

> Your intention is good but I think a safety net of the kind you
> propose would be slightly over the top.
> Basically you're trying to compensate for the user error who
> thinks the "branch" command should take her to an already existing
> branch while it does something completely different.
> Hence preventing the `git branch gtk-3-4` command from completion
> should there be a remote-tracking branch of the same name is just wrong
> IMO.  On the other hand, posting a hint might be OK.  I'm talking about
> something like this:

I'll say again: it would still be possible with an appropriate 'force' 
parameter.

> Anyway, this will make each call to git-branch to perform a crawl over
> the refs/heads hierarchy which, I think, is not worth the result.

I know branching is lightweight with git, but I don't understand that 
the operation is so performance-critical that a enumerating a directory 
and doing a few stats would be a huge issue...

If it is decided to only check the 'origin' remote then we're talking 
about one single stat() syscall.

Cheers