git branch case insensitivity (Possible bug)

git branch case insensitivity (Possible bug)

[Alexander Gallego]

Hello,

Here is a pastebin where I've reproduced the steps on a clean git repo.

http://pastebin.com/0vQZEat0



Brief description of the problem:



1.Basically one creates a local branch call it 'imp_fix' (branch off
master --> this doesn't matter)
2.One does work, commit, etc
3.One rebases imp_fix with master via: (inside imp_fix) git rebase master
4.One checks out master via: git checkout master
5.One merges an incorrect name "imp_Fix" (notice the capital F)
6.The expected output is that git would say, silly you --> that branch
does not exist.
7. Instead it merges (what I think is incorrectly) imp_fix.


Kindly let me know if I can provide more details.






For your convenience here is the paste:

agallego@agallego-macpro.local] /tmp
$ git clone git@bitbucket.org/agallego/gitbug
Cloning into 'gitbug'...
warning: You appear to have cloned an empty repository.

[agallego@agallego-macpro.local] /tmp
$ cd gitbug

[agallego@agallego-macpro.local] /tmp/gitbug
$ ls

[agallego@agallego-macpro.local] /tmp/gitbug
$ echo "Trying to reproduce a bug" > README

[agallego@agallego-macpro.local] /tmp/gitbug
$ ls
README

[agallego@agallego-macpro.local] /tmp/gitbug
$ git add .

[agallego@agallego-macpro.local] /tmp/gitbug
$ git commit -am "adding readme"
[master (root-commit) 0bfd62a] adding readme
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README

[agallego@agallego-macpro.local] /tmp/gitbug
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 230 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: bb/acl: agallego is allowed. accepted payload.
To git@bitbucket.org:agallego/gitbug
 * [new branch]      master -> master

[agallego@agallego-macpro.local] /tmp/gitbug
$ git checkout imp_fix
error: pathspec 'imp_fix' did not match any file(s) known to git.

[agallego@agallego-macpro.local] /tmp/gitbug
$ git branch imp_fix

[agallego@agallego-macpro.local] /tmp/gitbug
$ git checkout imp_fix
Switched to branch 'imp_fix'

[agallego@agallego-macpro.local] /tmp/gitbug
$ echo "imp_fix" >> README

[agallego@agallego-macpro.local] /tmp/gitbug
$ git commit -am "step 2, create an imp_fix branch and then merge"
[imp_fix 178c8f3] step 2, create an imp_fix branch and then merge
 1 files changed, 1 insertions(+), 0 deletions(-)

[agallego@agallego-macpro.local] /tmp/gitbug
$ ls
README

[agallego@agallego-macpro.local] /tmp/gitbug
$ git rebase master
Current branch imp_fix is up to date.

[agallego@agallego-macpro.local] /tmp/gitbug
$ git checkout master
Switched to branch 'master'

[agallego@agallego-macpro.local] /tmp/gitbug
$ git merge imp_Fix
Merge made by the 'recursive' strategy.
 README |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

[agallego@agallego-macpro.local] /tmp/gitbug
$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 392 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: bb/acl: agallego is allowed. accepted payload.
To git@bitbucket.org:agallego/gitbug
   0bfd62a..f99f8a1  master -> master






Sincerely,
Alexander Gallego

---*---
------*
*  *  *

Re: git branch case insensitivity (Possible bug)

[Andreas Ericsson]

On 01/09/2013 04:46 PM, Alexander Gallego wrote:
> Hello,
> 
> Here is a pastebin where I've reproduced the steps on a clean git repo.
> 
> http://pastebin.com/0vQZEat0
> 
> 
> 
> Brief description of the problem:
> 
> 
> 
> 1.Basically one creates a local branch call it 'imp_fix' (branch off
> master --> this doesn't matter)
> 2.One does work, commit, etc
> 3.One rebases imp_fix with master via: (inside imp_fix) git rebase master
> 4.One checks out master via: git checkout master
> 5.One merges an incorrect name "imp_Fix" (notice the capital F)
> 6.The expected output is that git would say, silly you --> that branch
> does not exist.
> 7. Instead it merges (what I think is incorrectly) imp_fix.
> 
> 
> Kindly let me know if I can provide more details.
> 

Are you using Mac OSX?
Are you using the HFS+ filesystem shipped with it?
Did you use the filesystem's default settings rather than reinstall your
system with sensible settings?

If you said "yes" to all of the above, this is a filesystem "feature",
courtesy of (cr)Apple, and you're screwed.

You can work around it by running "git pack-refs" every time you create
a branch or a tag though.

-- 
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 case insensitivity (Possible bug)

[Alexander Gallego]

On Wed, Jan 9, 2013 at 10:52 AM, Andreas Ericsson <ae@op5.se> wrote:
> On 01/09/2013 04:46 PM, Alexander Gallego wrote:
>> Hello,
>>
>> Here is a pastebin where I've reproduced the steps on a clean git repo.
>>
>> http://pastebin.com/0vQZEat0
>>
>>
>>
>> Brief description of the problem:
>>
>>
>>
>> 1.Basically one creates a local branch call it 'imp_fix' (branch off
>> master --> this doesn't matter)
>> 2.One does work, commit, etc
>> 3.One rebases imp_fix with master via: (inside imp_fix) git rebase master
>> 4.One checks out master via: git checkout master
>> 5.One merges an incorrect name "imp_Fix" (notice the capital F)
>> 6.The expected output is that git would say, silly you --> that branch
>> does not exist.
>> 7. Instead it merges (what I think is incorrectly) imp_fix.
>>
>>
>> Kindly let me know if I can provide more details.
>>
>
> Are you using Mac OSX?

Yes

> Are you using the HFS+ filesystem shipped with it?

Likely. I have not touched the fs settings.

> Did you use the filesystem's default settings rather than reinstall your
> system with sensible settings?

Yup. I use whatever was shipped with it.

> If you said "yes" to all of the above, this is a filesystem "feature",
> courtesy of (cr)Apple, and you're screwed.
>
> You can work around it by running "git pack-refs" every time you create
> a branch or a tag though.

Thanks for the tips. I'll be sure to use this.


> --
> 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 case insensitivity (Possible bug)

[Johannes Sixt]

Am 09.01.2013 18:03, schrieb Alexander Gallego:
> On Wed, Jan 9, 2013 at 10:52 AM, Andreas Ericsson <ae@op5.se> wrote:
>> [about case-insensitivity of HFS+ and branch names]
>> If you said "yes" to all of the above, this is a filesystem "feature",
>> courtesy of (cr)Apple, and you're screwed.
>>
>> You can work around it by running "git pack-refs" every time you create
>> a branch or a tag though.
> 
> Thanks for the tips. I'll be sure to use this.

Naah... that's unworkable. I'm sure the Andreas meant the suggestion
tongue-in-cheek. The important part of his reply is "you're screwed".

-- Hannes

Re: git branch case insensitivity (Possible bug)

[Joshua Jensen]

----- Original Message -----
From: Andreas Ericsson
Date: 1/9/2013 8:52 AM
>
> Are you using Mac OSX?
> Are you using the HFS+ filesystem shipped with it?
> Did you use the filesystem's default settings rather than reinstall your
> system with sensible settings?
>
> If you said "yes" to all of the above, this is a filesystem "feature",
> courtesy of (cr)Apple, and you're screwed.
>
> You can work around it by running "git pack-refs" every time you create
> a branch or a tag though.
There are two popular default file systems that are case preserving, 
case insensitive.  One is on Mac.  One is on Windows.

Since Git relies on file system behavior to store the equivalent of 
database entries like these refs, it cannot give a consistent user 
experience across platforms or even file systems within platforms.

That sounds like a bug in Git to me.

Perhaps pack-refs should be run automatically by any internal command 
that updates a ref to ensure a non-confusing, consistent user experience.

Further, if refs are no longer entries on the disk, then this nasty 
namespacing issue goes away.

User A:
$ git branch render
$ git push

User B:
$ git pull
$ git branch render/myfeature

render/myfeature can't be created, because Git assumes a filesystem 
structure.  The render namespace is locked out forever.

-Josh