Deal with conflicting branch names on case insensitive filesystems

[alfredodeza]

I am unable to clone a repo (over SSH) with gitifyhg v 0.8.1 and mercurial 2.6-rc.

Going through the bug list I found something similar, tried to enable full debug but unfortunately this repository is so gigantic that the whole output was bigger than 8GB.

This is the final portion (with DEBUG enabled):

DEBUG: 'INPUT: import refs/tags/4.3.95'
DEBUG: 'OUT: reset refs/hg/origin/tags/4.3.95'
DEBUG: 'OUT: from :12994'
DEBUG: 'OUT: '
DEBUG: 'INPUT: '
DEBUG: 'OUT: done'
warning: Not updating refs/hg/origin/branches/9-CURRENT (new tip 1b01034cf35539f2e3439a0c36f405453a2f1ea4 does not contain eea8e48f160609f2a8f1fb023b2b663bb8cdbb66)
fatal: Error while running fast-import
DEBUG: 'INPUT: '
Traceback (most recent call last):
  File "/Users/alfredo/.virtualenvs/gryphon/bin/git-remote-gitifyhg", line 9, in <module>
    load_entry_point('gitifyhg==0.8.1', 'console_scripts', 'git-remote-gitifyhg')()
  File "/Users/alfredo/.virtualenvs/gryphon/lib/python2.7/site-packages/gitifyhg/gitifyhg.py", line 262, in main
    HGRemote(*[x.decode('utf-8') for x in sys.argv[1:3]]).process()
  File "/Users/alfredo/.virtualenvs/gryphon/lib/python2.7/site-packages/gitifyhg/gitifyhg.py", line 175, in process
    self.marks.store()
  File "/Users/alfredo/.virtualenvs/gryphon/lib/python2.7/site-packages/gitifyhg/util.py", line 116, in store
    with self.storage_path.open('w') as file:
  File "/Users/alfredo/.virtualenvs/gryphon/lib/python2.7/site-packages/path.py-3.1-py2.7.egg/path.py", line 592, in open
    return open(self, mode)
IOError: [Errno 2] No such file or directory: path(u'/opt/gryphon/.git/hg/1003cb12f8afd51409473a5ab003b0c71cfe078c/marks-hg')

[alfredodeza]

And I get the same error if I try to clone from an existing hg repository on disk, if that is useful to know.

[PaulPrice]

Can you list the names of branches (even closed branches) in hg for this repo? This error appears similar to the one we get when we have branches 9-CURRENT and 9-CURRENT/foo.

[alfredodeza]

Yes, I do have a bunch of branches that look like:

feature/1-foo
feature/some-name
1-some_name
1.x-some_name

[dusty-phillips]

The exception itself tells us nothing, basically git saw that an error happened and deleted the .git directory, then gitifyhg tried to do something in that directory. I filed #79 for this.

The "not updating" warning may be related to the fact that there are two branches named:

9-current
9-CURRENT

Now git, mercurial, and gitifyhg are all case sensitive, so this should not normally be a problem.

And indeed, it is not a problem for me, I have cloned the repo in question successfully.

@alfredodeza I know you use a mac, is it possible you have a case insensitive filesystem? Maybe git is trying to store two refs with different names on the filesystem, and they are getting mapped to a single directory?

Also try the dev version of gitifyhg, just to exclude the possibility that it worked for me because of one of Paul's commits since 0.8.1.

[alfredodeza]

Yes, I am on a Mac with a case insensitive FS

[dusty-phillips]

Can you test what happens in git if you try to create a branch with the same name but different cases?

[alfredodeza]

@buchuki it fails with fatal: A branch named 'name' already exists.

[dusty-phillips]

@alfredodeza What if you clone https://github.com/buchuki/test_case_insensitive_branches ?

I want to find out how git handles the case where a linux user created case-sensitive branches and windows or mac users cloned it. It can't just fail permanently!! I want gitifyhg to do the same, whatever it is.

I haven't read through it yet, but http://thread.gmane.org/gmane.comp.version-control.git/188469 may be relevant.

[dusty-phillips]

one workaround that would alleviate (not prevent, but reduce) this issue and also speed up a lot of other processes would be to silently discard closed hg branches or at least offer a git config variable to silently discard closed branches. Sometimes a user would want access to that history, but in general, a closed hg branch is the equivalent of a deleted git branch, and the git user is rarely going to be interested in it.

[dusty-phillips]

In private conversation with @alfredodeza, he confirmed that he could clone the test repo that had branches with conflicting case insensitive names. Git seems to have some custom machinery that knows what to do in these cases. I haven't looked into how to trigger or emulate that, but packing refs is another option:

http://comments.gmane.org/gmane.comp.version-control.git/205210

[dusty-phillips]

@alfredodeza I haven't addressed the issue in this ticket yet, however, I believe you will be able to clone gryphon with gitifyhg 0.8.2, just released.

[alfredodeza]

@buchuki thank you sir, I was able to do so and now this works like a charm!