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.

Mysterious Dan
  • 1,316
  • 10
  • 25
  • 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. – tripleee May 31 '13 at 17:54
  • You might get lucky by using `git filter-branch --subdirectory-filter` – knittl May 31 '13 at 18:16
  • What I undestand here is that you see the '.' and you dont want too.right? – AAlferez May 31 '13 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. – Philip Oakley May 31 '13 at 19:46
  • Is your repository with the '.' public on github? I did not notice this artifact before, but will try to recreate your observation. -- Git.Unite author – tawman May 31 '13 at 20:35
  • I pushed my waldo repo from the blog post back up to GitHub and not seeing the a current directory entry '.' https://github.com/tawman/waldo - Git.Unite is basically the libgit2sharp move w/o the file.exists checks. – tawman May 31 '13 at 20:49
  • 2
    Nice, I was able to recreate the issue - https://github.com/tawman/git-unite/issues/1 - now need to find out what is causing it and fix it. Thanks. – tawman May 31 '13 at 21:04
  • @tawman +1 for the quick response. – Philip Oakley Jun 01 '13 at 07:44

1 Answers1

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.

tawman
  • 2,478
  • 1
  • 15
  • 24
  • 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! – Mysterious Dan May 31 '13 at 22:09
  • 1
    Excellent! Glad you were able to get past it and help me find a bug at the same time. – tawman Jun 01 '13 at 04:09