threads / bug / 16741

[usability bug] git branch -a does not disambiguate remote and local branches

Subject: [usability bug] git branch -a does not disambiguate remote and local branches

## tl;dr

6 messages between Dec 15, 2008 and Dec 16, 2008.

replies: 5people: 5as markdown or json

Constantine Plotnikov· Dec 15, 2008, 18:15 UTC · lore

Let's consider the following scenario:

mkdir bare.git mkdir local cd bare.git git --bare init cd ../local git init echo test > test.txt git add test.txt git commit -m test git remote add origin `pwd`/../bare.git git push --all git checkout -b origin/master master echo updated > test.txt git add test.txt git commit -m updated

Note that that in this scenario, the user has created local branch in the folder with the same name as a remote branch. While the supposed user here is apparently shooting itself in the foot, the scenario is still supported by git, and might happen as a result of more logical git operations (like git fetch).

After this scenario is executed, git branch -a will give the following output:
  master
* origin/master
  origin/master

Note that there is two origin/master entries, but it is not clear which is remote is and which is the local. I think that "git branch -a" should print unambiguous names, qualifying them if needed.

Constantine

Johannes Schindelin· Dec 15, 2008, 19:09 UTC · re: Constantine Plotnikov · lore

Re: [usability bug] git branch -a does not disambiguate remote and local branches

Hi,

On Mon, 15 Dec 2008, Constantine Plotnikov wrote:

Show 23 quoted lines

> Let's consider the following scenario:
> 
> mkdir bare.git
> mkdir local
> cd bare.git
> git --bare init
> cd ../local
> git init
> echo test > test.txt
> git add test.txt
> git commit -m test
> git remote add origin `pwd`/../bare.git
> git push --all
> git checkout -b origin/master master
> echo updated > test.txt
> git add test.txt
> git commit -m updated
> 
> Note that that in this scenario, the user has created local branch in
> the folder with the same name as a remote branch. While the supposed
> user here is apparently shooting itself in the foot, the scenario is
> still supported by git, and might happen as a result of more logical
> git operations (like git fetch).

It is only half-supported, and Git will complain, saying that there are ambiguous branches.

IMHO it is better to be nice to the many users who do not try to shoot themselves in the foot, by showing them the nice short names that will work.

The others are warned when they use the ambiguous short names anyway.

Ciao, Dscho

Constantine Plotnikov· Dec 15, 2008, 19:15 UTC · re: Johannes Schindelin · lore

Re: [usability bug] git branch -a does not disambiguate remote and local branches

On Mon, Dec 15, 2008 at 10:09 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 37 quoted lines

> Hi,
>
> On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
>
>> Let's consider the following scenario:
>>
>> mkdir bare.git
>> mkdir local
>> cd bare.git
>> git --bare init
>> cd ../local
>> git init
>> echo test > test.txt
>> git add test.txt
>> git commit -m test
>> git remote add origin `pwd`/../bare.git
>> git push --all
>> git checkout -b origin/master master
>> echo updated > test.txt
>> git add test.txt
>> git commit -m updated
>>
>> Note that that in this scenario, the user has created local branch in
>> the folder with the same name as a remote branch. While the supposed
>> user here is apparently shooting itself in the foot, the scenario is
>> still supported by git, and might happen as a result of more logical
>> git operations (like git fetch).
>
> It is only half-supported, and Git will complain, saying that there are
> ambiguous branches.
>
> IMHO it is better to be nice to the many users who do not try to shoot
> themselves in the foot, by showing them the nice short names that will
> work.
>
> The others are warned when they use the ambiguous short names anyway.
>

It is possible to be nice to to both categories showing shortest disambiguated output like:

  master
* heads/origin/master
  remotes/origin/master

Constantine

Boyd Stephen Smith Jr.· Dec 15, 2008, 19:21 UTC · re: Johannes Schindelin · lore

Re: [usability bug] git branch -a does not disambiguate remote and local branches

On Monday 2008 December 15 13:09:16 Johannes Schindelin wrote:

>IMHO it is better to be nice to the many users who do not try to shoot
>themselves in the foot, by showing them the nice short names that will
>work.

It should be possible to support both. Short names when they are unique, longer names when the short names are ambiguous.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/

Lars Hjemli· Dec 15, 2008, 19:24 UTC · re: Constantine Plotnikov · lore

Re: [usability bug] git branch -a does not disambiguate remote and local branches

On Mon, Dec 15, 2008 at 19:15, Constantine Plotnikov <constantine.plotnikov@gmail.com> wrote:

Show 7 quoted lines

> After this scenario is executed, git branch -a will give the following output:
>  master
> * origin/master
>  origin/master
>
> Note that there is two origin/master entries, but it is not clear
> which is remote is and which is the local.

You can use `git branch -a --color` to see the difference (issue `git config --global color.branch true` to use --color automatically).

-- larsh

Björn Steinbrink· Dec 16, 2008, 06:26 UTC · re: Constantine Plotnikov · lore

Re: [usability bug] git branch -a does not disambiguate remote and local branches

On 2008.12.15 21:15:15 +0300, Constantine Plotnikov wrote:

Show 8 quoted lines

> After this scenario is executed, git branch -a will give the following output:
>   master
> * origin/master
>   origin/master
> 
> Note that there is two origin/master entries, but it is not clear
> which is remote is and which is the local. I think that "git branch
> -a" should print unambiguous names, qualifying them if needed.

Actually, it is clear. The one with the * is the local one. The remote tracking branch will never be marked as checked out, as you would get a detached HEAD when you do "git checkout remotes/origin/master".

When there are duplicate entries, you can be sure that you have a local branch head and a remote tracking branch with the same shortname. And when one of them has been marked as checked out, you can be sure that it is the local one.

Björn