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

From: Phil Hord <phil.hord@gmail.com>
Date: Jun 19, 2012, 23:21 UTC
Message-ID: <CABURp0p6Hv8=Yg1MNb_DMRM3D2JWZtGNwn_GiOfP_x3MctrJ9A@mail.gmail.com>
In-Reply-To: <4FE0E493.1010308@desrt.ca>

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

Show 24 quoted lines

> 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