1

I used the Git.Unite tool (http://www.woodcp.com/2013/01/git-unite-fix-case-sensitive-file-paths-on-windows/) to merge paths in my git repo that differed only in case, and while it succeeded at that, it also seems to have added a '.' entry to my repository. Of course, when I clone the repo to my local machine, the '.' is invisible (since there's the OS-provided virtual entry) but when I browse the repo in github, I can see a '.' entry that unsurprisingly points to the current directory. It seems silly and confusing that the entry is there, but I also don't know how to delete it, since saying git rm . doesn't quite have the right meaning.

What can I do to get rid of this bogus entry?

Edit: to be clear, the problem seems to be that the tool expressed the renames as Foo/Bar.txt -> ./Foo/Bar.txt, which created an explicit '.' entry.

Edit 2: I just remembered that git doesn't explicitly store directory entries, so I think github is only showing . because I have a few files that are represented in the tree with a path starting with .. I'll probably just remove and re-add those files for now, since git mv won't let me rename them.

Improve this question
8
  • 3
    I think you are beyond the "safe" point here anyhow. This sounds like a good opportunity to learn about the murky internals. Make a clone of your repo, ditch it and start over when you make a mistake. Commented May 31, 2013 at 17:54
  • You might get lucky by using git filter-branch --subdirectory-filter Commented May 31, 2013 at 18:16
  • What I undestand here is that you see the '.' and you dont want too.right? Commented May 31, 2013 at 18:29
  • Sounds like a 'bug' in the tool and its interaction with whichever windows' git version is in use, that has created an extra directory level that is called '.' At least that is how I read the stated facts. Commented May 31, 2013 at 19:46
  • 2
    Nice, I was able to recreate the issue - github.com/tawman/git-unite/issues/1 - now need to find out what is causing it and fix it. Thanks. Commented May 31, 2013 at 21:04

1 Answer 1

Reset to default
2

I found an issue with Git.Unite when running the tool against the current directory by passing '.' as the path argument:

C:\demo [master]> C:\tools\Git.Unite.exe .

As you observed, it was issuing an index move targeting the leading ./directory name. I have pushed up a fix to my Git.Unite repository that resolves the user passed path to the full directory name in order to avoid this problem.

To correct your repository, git reset --hard HEAD~ to before the commit after running Git.Unite and re-run the new build of Git.Unite.

If you run into any issues, please open a GitHub issue to expedite the fix. Thanks for the feedback and hope the tool helps out.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Unfortunately the repo is not public, and resetting the repo is not possible (it's already been pushed and others have pulled it), but my simple solution of deleting the files in question (just a handful) did solve it for me. Thanks!
Excellent! Glad you were able to get past it and help me find a bug at the same time.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.