'git branch' when origin branch with same name exists

'git branch' when origin branch with same name exists

[Ryan Lortie]

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?

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

[jaseem abid]

On Tue, Jun 19, 2012 at 8:21 PM, Ryan Lortie <desrt@desrt.ca> 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

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

[Michael Schubert]

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.

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

[Ryan Lortie]

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

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

[Philippe Vaucher]

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

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

[Angus Hammond]

> 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

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

[Konstantin Khomoutov]

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

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

[Ryan Lortie]

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

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

[Andreas Ericsson]

On 06/19/2012 07:06 PM, Ryan Lortie wrote:
> 
>> 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.

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

[Thomas Rast]

Ryan Lortie <desrt@desrt.ca> writes:

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

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@{inf,student}.ethz.ch

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

[Junio C Hamano]

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

> Ryan Lortie <desrt@desrt.ca> writes:
>
>> 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.
>
> 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?

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

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

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.

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

[Ryan Lortie]

hi,

On 12-06-19 02:31 PM, Junio C Hamano wrote:
> 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.

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

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

[Junio C Hamano]

Ryan Lortie <desrt@desrt.ca> writes:

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

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.

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

[Ryan Lortie]

hi,

On 12-06-19 05:32 PM, Junio C Hamano wrote:
> 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.

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

Cheers

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

[Phil Hord]

On Tue, Jun 19, 2012 at 4:44 PM, Ryan Lortie <desrt@desrt.ca> wrote:
> hi,
>
>
> On 12-06-19 02:31 PM, Junio C Hamano wrote:
>>
>> 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.
>
>
> 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').

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

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

[Junio C Hamano]

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

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

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.

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

[Matthieu Moy]

Junio C Hamano <gitster@pobox.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.

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
http://www-verimag.imag.fr/~moy/

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

[Junio C Hamano]

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

> Junio C Hamano <gitster@pobox.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.
>
> 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

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.

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

[Junio C Hamano]

Ryan Lortie <desrt@desrt.ca> writes:

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

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.