threads / bug / 42543

Minor Bug in Renaming Branches

Subject: Minor Bug in Renaming Branches

## tl;dr

7 messages between Jun 6, 2016 and Jun 7, 2016.

replies: 6people: 4as markdown or json

Samuel Lijin· Jun 6, 2016, 17:52 UTC · lore
Hi,

Not quite sure where to submit bug reports about Git, this was the best I could find, so if there's a better place to do this, please let me know and I will.

The short of this issue is that on Mac and Windows, if a branch has a slash in its name, changing it from lowercase to uppercase requires diving into .git/refs/heads/ and manually moving stuff around - I think the behavior should be at least something like this: http://stackoverflow.com/questions/26810252/how-to-change-my-local-github-branch-name-to-uppercase.

It happens that on both Windows box, to rename a branch from
"branch/name" to "BRANCH/NAME", one has to actually dive into
.git/refs/heads/ because of how Windows handles upper/lowercase in
directory paths. (Win7, mingw64 via Git for Bash, git version
2.7.0.windows.1)
user@windows-box MINGW64 ~
$ mkdir sandbox && cd sandbox && git init
Initialized empty Git repository in C:/Users/user/sandbox/.git/
user@windows-box MINGW64 ~/sandbox (master)
$ touch empty.txt && git add empty.txt && git commit -m 'initialize repo'
[master (root-commit) 761113d] initialize repo
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 empty.txt
user@windows-box MINGW64 ~/sandbox (master)
$ git branch
* master
user@windows-box MINGW64 ~/sandbox (master)
$ git checkout -b branch/name
Switched to a new branch 'branch/name'
user@windows-box MINGW64 ~/sandbox (branch/name)
$ git branch
* branch/name
  master
user@windows-box MINGW64 ~/sandbox (branch/name)
$ git branch -m BRANCH/NAME
fatal: A branch named 'BRANCH/NAME' already exists.
user@windows-box MINGW64 ~/sandbox (branch/name)
$ git branch -m tmp
user@windows-box MINGW64 ~/sandbox (tmp)
$ git branch -m BRANCH/NAME
user@windows-box MINGW64 ~/sandbox (BRANCH/NAME)
$ git branch
  branch/NAME
  master
user@windows-box MINGW64 ~/sandbox (BRANCH/NAME)
$ mv .git/refs/heads/branch/ .git/refs/heads/BRANCH/
user@windows-box MINGW64 ~/sandbox (BRANCH/NAME)
$ git branch
* BRANCH/NAME
  master

Interestingly, from inside an Ubuntu VM (with the directory in question mounted as a VBox fileshare), this is not an issue.

A colleague on a Mac also reproduces the issue successfully (OSX 10.11.5, git 2.8.3):

mac-box:sandbox user$ touch empty.txt && git add empty.txt && git
commit -m 'initial commit'
[master (root-commit) 1f4f1fa] initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 empty.txt
mac-box:sandbox user$ git branch
* master
mac-box:sandbox user$ git checkout -b branch/name
Switched to a new branch 'branch/name'
mac-box:sandbox user$ git branch -m BRANCH/NAME
fatal: A branch named 'BRANCH/NAME' already exists.
mac-box:sandbox user$ git branch
* branch/name
  master
mac-box:sandbox user$ git branch -m tmp
mac-box:sandbox user$ git branch
  master
* tmp
mac-box:sandbox user$ git branch -m BRANCH/NAME
mac-box:sandbox user$ git branch
  branch/NAME
  master
mac-box:sandbox user$ mv .git/refs/heads/branch/ .git/refs/heads/BRANCH/
mac-box:sandbox user$ git branch
* BRANCH/NAME
  master

Thanks, Sam

Stefan Beller· Jun 6, 2016, 18:09 UTC · re: Samuel Lijin · lore

Re: Minor Bug in Renaming Branches

On Mon, Jun 6, 2016 at 10:52 AM, Samuel Lijin <samuel.lijin@formlabs.com> wrote:
> user@windows-box MINGW64 ~/sandbox (branch/name)
> $ git branch -m BRANCH/NAME
> fatal: A branch named 'BRANCH/NAME' already exists.

Yeah, branches/refs are treated as if they are files on a file system (which they are currently). So depending on the file system used you have problems with case sensitive things.

Torsten Bögershausen· Jun 6, 2016, 19:17 UTC · re: Samuel Lijin · lore

Re: Minor Bug in Renaming Branches

On 06.06.16 19:52, Samuel Lijin wrote:
Show 88 quoted lines
> Hi,
> 
> Not quite sure where to submit bug reports about Git, this was the
> best I could find, so if there's a better place to do this, please let
> me know and I will.
> 
> The short of this issue is that on Mac and Windows, if a branch has a
> slash in its name, changing it from lowercase to uppercase requires
> diving into .git/refs/heads/ and manually moving stuff around - I
> think the behavior should be at least something like this:
> http://stackoverflow.com/questions/26810252/how-to-change-my-local-github-branch-name-to-uppercase.
> 
> It happens that on both Windows box, to rename a branch from
> "branch/name" to "BRANCH/NAME", one has to actually dive into
> .git/refs/heads/ because of how Windows handles upper/lowercase in
> directory paths. (Win7, mingw64 via Git for Bash, git version
> 2.7.0.windows.1)
> user@windows-box MINGW64 ~
> $ mkdir sandbox && cd sandbox && git init
> Initialized empty Git repository in C:/Users/user/sandbox/.git/
> user@windows-box MINGW64 ~/sandbox (master)
> $ touch empty.txt && git add empty.txt && git commit -m 'initialize repo'
> [master (root-commit) 761113d] initialize repo
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  create mode 100644 empty.txt
> user@windows-box MINGW64 ~/sandbox (master)
> $ git branch
> * master
> user@windows-box MINGW64 ~/sandbox (master)
> $ git checkout -b branch/name
> Switched to a new branch 'branch/name'
> user@windows-box MINGW64 ~/sandbox (branch/name)
> $ git branch
> * branch/name
>   master
> user@windows-box MINGW64 ~/sandbox (branch/name)
> $ git branch -m BRANCH/NAME
> fatal: A branch named 'BRANCH/NAME' already exists.
> user@windows-box MINGW64 ~/sandbox (branch/name)
> $ git branch -m tmp
> user@windows-box MINGW64 ~/sandbox (tmp)
> $ git branch -m BRANCH/NAME
> user@windows-box MINGW64 ~/sandbox (BRANCH/NAME)
> $ git branch
>   branch/NAME
>   master
> user@windows-box MINGW64 ~/sandbox (BRANCH/NAME)
> $ mv .git/refs/heads/branch/ .git/refs/heads/BRANCH/
> user@windows-box MINGW64 ~/sandbox (BRANCH/NAME)
> $ git branch
> * BRANCH/NAME
>   master
> 
> Interestingly, from inside an Ubuntu VM (with the directory in
> question mounted as a VBox fileshare), this is not an issue.
> 
> A colleague on a Mac also reproduces the issue successfully (OSX
> 10.11.5, git 2.8.3):
> 
> mac-box:sandbox user$ touch empty.txt && git add empty.txt && git
> commit -m 'initial commit'
> [master (root-commit) 1f4f1fa] initial commit
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  create mode 100644 empty.txt
> mac-box:sandbox user$ git branch
> * master
> mac-box:sandbox user$ git checkout -b branch/name
> Switched to a new branch 'branch/name'
> mac-box:sandbox user$ git branch -m BRANCH/NAME
> fatal: A branch named 'BRANCH/NAME' already exists.
> mac-box:sandbox user$ git branch
> * branch/name
>   master
> mac-box:sandbox user$ git branch -m tmp
> mac-box:sandbox user$ git branch
>   master
> * tmp
> mac-box:sandbox user$ git branch -m BRANCH/NAME
> mac-box:sandbox user$ git branch
>   branch/NAME
>   master
> mac-box:sandbox user$ mv .git/refs/heads/branch/ .git/refs/heads/BRANCH/
> mac-box:sandbox user$ git branch
> * BRANCH/NAME
>   master
> 
> Thanks,
> Sam

A limitation is introduced by Mac OS and Windows: BRANCH/NAME and branch/name refer to the same object in the file system. As a workaround, you can pack the branch names: git pack-refs --all or, that is my preference, avoid using the same name upper- and lower-case.

Show 5 quoted lines
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Stefan Beller· Jun 6, 2016, 19:35 UTC · re: Torsten Bögershausen · lore

Re: Minor Bug in Renaming Branches

On Mon, Jun 6, 2016 at 12:17 PM, Torsten Bögershausen <tboegi@web.de> wrote:
Show 5 quoted lines
> A limitation is introduced by Mac OS and Windows:
> BRANCH/NAME and branch/name refer to the same object in the file
> system.
> As a workaround, you can pack the branch names:
> git pack-refs --all

Once you packed a branch into the packed refs file, you can create another loose branch of different capitalization, which then 'hides' the packed ref?

That sounds error prone to me, as a seemingly unrelated branch changed its value:

    git branch BRANCH 012345
    git pack-refs --all
    git branch branch BRANCH^
    git rev-parse BRANCH
    (I'd expect BRANCH^ as return)

(I don't have a windows machine for testing here, so that is pure speculation)

Thanks, Stefan

Torsten Bögershausen· Jun 7, 2016, 04:13 UTC · re: Stefan Beller · lore

Re: Minor Bug in Renaming Branches

On 06/06/2016 09:35 PM, Stefan Beller wrote:
Show 24 quoted lines
> On Mon, Jun 6, 2016 at 12:17 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>
>> A limitation is introduced by Mac OS and Windows:
>> BRANCH/NAME and branch/name refer to the same object in the file
>> system.
>> As a workaround, you can pack the branch names:
>> git pack-refs --all
>
> Once you packed a branch into the packed refs file, you can
> create another loose branch of different capitalization,
> which then 'hides' the packed ref?
>
> That sounds error prone to me, as a seemingly unrelated branch
> changed its value:
>
>      git branch BRANCH 012345
>      git pack-refs --all
>      git branch branch BRANCH^
>      git rev-parse BRANCH
>      (I'd expect BRANCH^ as return)
>
> (I don't have a windows machine for testing here, so that
> is pure speculation)
>

Yes, another reason not to use branch and BRANCH in the same repo. (You can test under Linux & vfat)

Eric Deplagne· Jun 7, 2016, 07:40 UTC · re: Torsten Bögershausen · lore

Re: Minor Bug in Renaming Branches

On Tue, 07 Jun 2016 06:13:14 +0200, Torsten Bögershausen wrote:
Show 27 quoted lines
> On 06/06/2016 09:35 PM, Stefan Beller wrote:
>> On Mon, Jun 6, 2016 at 12:17 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>
>>> A limitation is introduced by Mac OS and Windows:
>>> BRANCH/NAME and branch/name refer to the same object in the file
>>> system.
>>> As a workaround, you can pack the branch names:
>>> git pack-refs --all
>>
>> Once you packed a branch into the packed refs file, you can
>> create another loose branch of different capitalization,
>> which then 'hides' the packed ref?
>>
>> That sounds error prone to me, as a seemingly unrelated branch
>> changed its value:
>>
>>      git branch BRANCH 012345
>>      git pack-refs --all
>>      git branch branch BRANCH^
>>      git rev-parse BRANCH
>>      (I'd expect BRANCH^ as return)
>>
>> (I don't have a windows machine for testing here, so that
>> is pure speculation)
>>
> Yes, another reason not to use branch and BRANCH in the same repo.
> (You can test under Linux & vfat)
  Or to have git just refuse it altogether...
  But let me guess, it's against some sort of policy...
  There could be some hook out there, then ?
-- 
  Eric Deplagne
Stefan Beller· Jun 7, 2016, 13:09 UTC · re: Eric Deplagne · lore

Re: Minor Bug in Renaming Branches

On Tue, Jun 7, 2016 at 12:40 AM, Eric Deplagne <Eric@deplagne.name> wrote:
Show 30 quoted lines
> On Tue, 07 Jun 2016 06:13:14 +0200, Torsten Bögershausen wrote:
>> On 06/06/2016 09:35 PM, Stefan Beller wrote:
>>> On Mon, Jun 6, 2016 at 12:17 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>>
>>>> A limitation is introduced by Mac OS and Windows:
>>>> BRANCH/NAME and branch/name refer to the same object in the file
>>>> system.
>>>> As a workaround, you can pack the branch names:
>>>> git pack-refs --all
>>>
>>> Once you packed a branch into the packed refs file, you can
>>> create another loose branch of different capitalization,
>>> which then 'hides' the packed ref?
>>>
>>> That sounds error prone to me, as a seemingly unrelated branch
>>> changed its value:
>>>
>>>      git branch BRANCH 012345
>>>      git pack-refs --all
>>>      git branch branch BRANCH^
>>>      git rev-parse BRANCH
>>>      (I'd expect BRANCH^ as return)
>>>
>>> (I don't have a windows machine for testing here, so that
>>> is pure speculation)
>>>
>> Yes, another reason not to use branch and BRANCH in the same repo.
>> (You can test under Linux & vfat)
>
>   Or to have git just refuse it altogether...

Maybe we could refuse creation of case different branch names on case insensitive file systems, but you could have created them on a case sensitive file system, so you still have to work with that.

This topic was discussed at the Git Merge this year (again), and IIRC the outcome was to not restrict outselves to the lowest common denominator, but rather ¯\_(ツ)_/¯. People who use case insensitive file systems are aware of their limitations and would not ever want to do such branch tricks, right? ;)

>
>   But let me guess, it's against some sort of policy...

I rather think nobody stepped up to present a solution that doesn't suck. As by the title of this thread, it's rather minor.

>
>   There could be some hook out there, then ?
The hook to tell the user if that branch name is allowed?

My gut reaction to that is, that such a hook would violate the principles of the DVCS thinking. A user ought to do anything they want locally including having naming rights for their local branches, so we'd not want to restrict them?

Show 12 quoted lines
>
> --
>   Eric Deplagne
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD4DBQFXVnqDej7DisjVpq4RAqxoAJ0eufoN3OXWKGiHrAPolS4SmOHGIwCWJHNl
> jI/aVh12/NM8YZX5oEl4Ww==
> =rwxP
> -----END PGP SIGNATURE-----
>

← back to recent threads