Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deal with conflicting branch names on case insensitive filesystems #78

Open
alfredodeza opened this issue Apr 29, 2013 · 12 comments
Open

Comments

@alfredodeza
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Owner

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
Copy link
Contributor Author

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

@dusty-phillips
Copy link
Owner

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

@alfredodeza
Copy link
Contributor Author

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

@dusty-phillips
Copy link
Owner

@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
Copy link
Owner

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
Copy link
Owner

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 pushed a commit that referenced this issue Apr 30, 2013
Fixes #80.

This is a controversial fix in some ways; an earlier commit explicitly turned on cloning of closed branches. However, I feel that the default should be to not clone closed branches. There are a few reasons for this.

The main one is that a closed branch in mercurial is generally considered the equivalent of a deleted branch in git. Therefore, we do not want the deleted branch in git.

A second one is that cloning closed branches can take a great deal of time that is, for the above reason, completely wasted.

A third one is that we have a few problems with branch naming (eg #78, #75, #62) that are caused by conflicting branched names. This fix does not solve those issues, but when the conflicting branches are closed branches, it does prevent them from causing a clone to fail outright.
@dusty-phillips
Copy link
Owner

@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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants