Minor Bug in Renaming Branches

Minor Bug in Renaming Branches

[Samuel Lijin]

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

Re: Minor Bug in Renaming Branches

[Stefan Beller]

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.

Re: Minor Bug in Renaming Branches

[Torsten Bögershausen]

On 06.06.16 19:52, Samuel Lijin wrote:
> 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.



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

Re: Minor Bug in Renaming Branches

[Stefan Beller]

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)

Thanks,
Stefan

Re: Minor Bug in Renaming Branches

[Torsten Bögershausen]

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)

Re: Minor Bug in Renaming Branches

[Eric Deplagne]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

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

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

  There could be some hook out there, then ?

-- 
  Eric Deplagne

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Minor Bug in Renaming Branches

[Stefan Beller]

On Tue, Jun 7, 2016 at 12:40 AM, Eric Deplagne <Eric@deplagne.name> wrote:
> 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?

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