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 -- 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