'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 [off-list ref] wrote:

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?

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

-- 
Jaseem Abid
http://jaseemabid.github.com

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

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?

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:

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

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

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

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 [off-list ref] wrote:

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.

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.

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:

[...]

or something like that.

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.

Thoughts?

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.

quoted

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

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

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

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

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

quoted

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.

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.