'git branch' when origin branch with same name exists

hi,

After helping someone on IRC who got themselves into a bit of a problem, I have a feature request for git.

In this case, the user wanted to checkout a branch of a module.  They did:

   git clone git://git.gnome.org/gtk+
   cd gtk+
   git branch gtk-3-4

Obviously this is a user error, but it's a pretty innocent one, and puts the user in a bad state. When they figure they should have typed "git checkout gtk-3-4" it is already too late -- they will be taken onto their locally-created copy of the master branch.

So feature request: 'git branch' should not allow creating a local branch that has the same name as a branch that already exists on 'origin' (or any remote?) without some sort of --force flag. It could instead helpfully say:

   """

     The branch you are trying to create already exists on the origin.
     Are you sure you don't want to checkout this branch using
     'git checkout gtk-3-4'

  """

or something like that.

Thoughts?

On Tue, Jun 19, 2012 at 8:21 PM, Ryan Lortie <desrt@desrt.ca> wrote:

Dont know much about this but to me it looks like a good feature.

On 06/19/2012 04:51 PM, Ryan Lortie wrote:

This very much violates the distributed nature of Git. Everything is allowed, because it's *my* repository.

hi Michael,

On 12-06-19 11:35 AM, Michael Schubert wrote:

It is certainly allowed, as originally mentioned, with a --force option of some kind.

It is only prevented by default because it is likely you are making a mistake...

Cheers

I second that, way more often than not it *is* a mistake to create a branch with the same name as one in a remote. In the unlikely scenario where it is what you want, I think asking for a -f/--force is not too much.

I think the feature request is in sync with "git branch -d" refusing to delete an unmerged branch because it's unlikely that it's what you want, and forces you to use -D instead.

Philippe

By the sounds of it everything still would be allowed for a user who knew that they wanted to create a branch even if it did have a conflicting name. However (that I can think of) this is not something you usually want to do, so it's reasonable to assume that when this happens it's usually user error, so git should tell the user what it thinks they meant to do and also give them the option to carry on anyway (probably with a -f flag).

This is (I think) exactly what git already does with local branches.

Thanks Angus

On Tue, 19 Jun 2012 10:51:39 -0400 Ryan Lortie <desrt@desrt.ca> 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.

[...]

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.

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:

$ git branch gtk-3-4 The remote "origin" has the branch of the same name. The created branch is not set to track it.

Such a hint would state the obvious thing but it would alert a user who would not expect it (and hopefully make her google or ask for assistance using this hint's message).

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.

hi,

On 12-06-19 12:06 PM, Konstantin Khomoutov wrote:

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

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

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

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

On 06/19/2012 07:06 PM, Ryan Lortie wrote:

Not really. I don't remember which repository it was, but the "packed-refs" feature came about as a result of one repository having in excess of 120k refs. So your "a few stat() calls" could well end up nuking performance totally for someone else, and "one stat call for origin" is only true if origin only has one ref, which is obviously not the case for some of the larger projects.

In general, assuming everyone else uses a piece of software the same way you do is a recipe for creating poorly performing programs.

Ryan Lortie <desrt@desrt.ca> writes:

How does this fit with the fact that git has forever(?) created a 'master' branch when cloning, and usually points it at origin/master too?

I honestly haven't decided whether I should like or hate your proposal, but ISTM that outlawing an operation that git does on every clone is a bit moot.

Thomas Rast <trast@student.ethz.ch> writes:

A big difference is that it by default is set to integrate with origin/master.

I am sympathetic to this particular example of the user regretting that he has said "git branch" when he meant "git checkout", and also am sympathetic to the wish that "git branch" somehow figured out the situation and offered an advice, or outsmarted the user and forbade the operation. But I do not think "git branch" can sensibly and correctly make that decision for the user---at least I do not sense any of the people who is in this thread has clear idea on what to base that decision on, and "the same name appears in an existing remote" is not it. "The same name appears, and the new branch is not set to integrate with it" may be closer, but that may forbid valid use cases too much.

hi,

On 12-06-19 02:31 PM, Junio C Hamano wrote:

My originally intended point was that it should be prevented in the case where 'git branch' is given no additional arguments (ie: implicitly creating the branch from HEAD). Obviously it should be possible to create a 'gtk-3-4' branch that is based on the origin one. In any case, I should have made that more clear.

So to restate the feature request more clearly: "git branch X" with no explicitly specified start-point should prevent the branch "X" from being created when a branch with the same name already exists on a remote (perhaps only considering 'origin').

When stated in this more explicit way, it becomes clear that a --force option would not even be required; you could just say:

   git branch gtk-3-4 HEAD

to make it clear that this was your intention.

Nobody making a casual mistake would type that in full.

Cheers

Ryan Lortie <desrt@desrt.ca> writes:

Won't happen. "git branch new-branch-name" has always been the way to create from HEAD. Suddenly requiring an extra argument is a grave usability regression.

hi,

On 12-06-19 05:32 PM, Junio C Hamano wrote:

Reminder: we're talking only about the case where an unrelated branch 
with the same name already exists upstream...

Cheers

On Tue, Jun 19, 2012 at 4:44 PM, Ryan Lortie <desrt@desrt.ca> wrote:

I'll second the suggestion to offer advice to a user who does this, possibly even including "undo" commands in case it was a mistake. But Junio is right, of course, that the request that this "should prevent" the action it previously explicitly did -- as documented, even -- is a non-starter. Aside from the user interaction problem, it will also break scripts in ways that may go undetected until they wreak nasty havoc on some unsuspecting git robot.

Maybe you can suggest the advice verbiage which you think would have helped this user.

Phil

Phil Hord <phil.hord@gmail.com> writes:

Requiring starting point and failing without --force will never happen, but it could be a possible approach to issue an additional advice message under reasonably narrow conditions, namely:

 - The starting point was not given explicitly;

 - It would have DWIMed to "git checkout -t -b it origin/it" when
   creating the branch (I think you need to check configurations
   like branch.autosetupmerge and existence of the tracking branch
   remotes/origin/it); and

 - advice.branchNotTrackingCorrespondingRemote is not set to false.

Junio C Hamano <gitster@pobox.com> writes:

I like that. Stg like

$ git branch next Creating local branch next starting from <sha1>. If you meant to checkout a new branch 'next' to track remote branch 'next' from 'origin', run these commands now: git branch -d next; git checkout next

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Oh, another precondition would be that --force was _not_ given.

It is fairly clear "git branch -f next" is asking to forcibly update an existing local 'next' to the current HEAD, not to origin/next, and giving the above suggestion will be mildly irritating in such a case.

Ryan Lortie <desrt@desrt.ca> writes:

I think "the same name" is missing the point. It is perfectly fine to have your own 'fix' branch that builds on top of what the remote side calls 'master', with the intention of testing what you queue on your 'fix' branch locally and cherry-picking proven-good ones to your 'master' before pushing the result out, even when there happens to be a 'fix' branch that your 'fix' branch does not have anything to do with on the remote side. After all, the remote side may start using the 'fix' branch _long_ _after_ you start using your 'fix' branch, so checking at the branch creation time does not help you much, even if it were a problem that your local 'fix' (which you have no intention to push it to the remote) and the 'fix' at the remote does not have any common purpose.

The same can be said for the gtk-3-4 branch, depending on the purpose of 'master' vs purpose of 'gtk-3-4' at the remote side. If 'gtk-3-4' branch were the playground to come up with the next great version, and 'master' is the continuation of the current version with not so earth-shattering changes, it is perfectly normal for different contributors to fork from 'master' for their next feature that they hope eventually to go to 'gtk-3-4' at the remote, and locally name the branch 'gtk-3-4', build their feature, and depending on how disruptive the change is, choose to integrate the result into either 'master' or'gtk-3-4' at the remote after it is done. So it is not immediately clear if "git branch gtk-3-4" in the example is a problem to begin with.

Given that "git checkout gtk-3-4" with recent enough Git (since 1.7.0) DWIMs the command to do the equivalent of

	git checkout -t gtk-3-4 origin/gtk-3-4

that is, to fork, build on top of, and to be integrated with the 'gtk-3-4' branch at the 'origin', if you know with a reasonable degree of certainty that the user should have typed "git checkout gtk-3-4" when he typed "git branch gtk-3-4" in the example, then it could be argued that "git branch" could offer an advice message, but it is unclear how you can be sure if "git checkout gtk-3-4" was what the user really wanted to do when he said "git branch gtk-3-4" in the first place.