How to recover from git-svn putting a different cased dulplicate file in the repository?

Question

Git-svn allowed for a duplicate filename, just with different case, to be added to our subversion repository.

On Windows this meant that subversion could not checkout the file, complaining of a duplicate.

Another developer deleted the incorrectly cased version from the repository. Now when trying to do a git-svn rebase I get a "could not detach HEAD" message and a complaint about the file name in question being untracked and needing to be overwritten. Deleting the file makes git-svn complain that the file needs to be updated.

Is the only solution to copy the repository to a machine with a case sensitive filesystem do the rebase then move it back?

I understand that git-svn isn't ready for real world work on Windows but I'd like to recover from this mess it has created.

Answer 1

The same way you always solve this problem under Windows. You have to rename one of the files, then you can restore the other one.

Answer 2

I ran into a similar problem with Git (alone, not even with git-svn) getting very confused about changing the case of filenames when using a case-insensitive Mac filesystem. I didn't find a solution to fix the repository on the case-insensitive filesystem, but instead created a new case-sensitive volume in a .dmg file, mounted that, and used Git on that volume instead.

You may find that some of the Git "plumbing" commands might be helpful. For example, git checkout-index has a -f flag to force overwriting of existing files (also use -a with that command otherwise it might not do anything). The plumbing commands are generally more powerful (and more dangerous) than the porcelain commands, but may give you the flexibility you need to fix this.