• when I began moving a second project from CVS, one unexpected difficulty was that Git doesn’t support putting empty directories in version control but CVS does. (I found this because I did a recursive diff of the directory trees checked out from CVS and from Git.) I had to create a hidden file for each such directory that had been in CVS, so that Git would have a file to commit. I called it .keep so it would be a hidden file (on Linux at least), and put a couple of lines inside explaining why it was there.
• so far the biggest problem has been the SOCKS proxy that our ssh connections have to go through, rather than Git itself. Once someone gets to the point where they can ssh to our server through the proxy using key-based authentication, the worst is usually over.
• Eclipse has been a pain point:
  • for the EGit plugin in Eclipse to work through the proxy, the environment variable GIT_SSH needs to be set correctly. This causes EGit to use an external ssh implementation instead of its internal one. We had to use ssh keys without a passphrase, because we couldn’t get Eclipse to prompt for one. (I’ve seen other posts that it should – perhaps the behavior changed with Eclipse 4.0?)
  • another oddity: on some systems Eclipse wouldn’t see this environment variable until Windows was rebooted. We’re running Windows 7 64-bit. I did not see this myself, but rebooting has become my go to recommendation when things just aren’t working the way they should.  (It’s Windows, after all.)
• there’s been a minor recurring difficulty – writing about it. When updating our internal wiki pages: “Git” looks odd, “git” doesn’t look like a name.

The biggest remaining challenge may well be making a part of a CVS repository read-only… So far I’ve found at least 4 ways to do that, and the simple one didn’t work.

When I started on this I hoped to find something that allowed the sort of easy coexistence that git-svn does, but no such luck. There are two tools for importing from CVS to Git that I tried: git-cvs and cvs2git.

• git-cvs: this uses git cvsimport and has a dcommit command like git-svn.
  • the import appeared to work, but when I attempted to build the code the build failed. A small number of files in Git were at older revisions than they were in CVS. It seemed that the newer revisions simply didn’t get imported.
  • git-cvs supports incremental imports to an existing repository. I used this for over 6 months before switching to cvs2git, to track the ongoing changes in CVS, so that I could use git’s tools to look at changesets, find the origins of changes, and visualize and search the history of changes across multiple branches.
  • I was hoping to use this to do the final import, but could find no errors to explain why some of the files were at older revisions.
• cvs2git: this is part of the cvs2svn project, which can make the documentation a bit confusing at times, but with a little experimentation it becomes clear.
  • after importing to git and cloning the repository, I recursively compared the files with a CVS checkout done at the same time. The only difference was where there were tags that CVS expands on checkout, because git doesn’t expand those tags.
  • there’s no way to do an incremental import into an existing repository; you have to start over every time. This means that the cutover has to be a big-bang style, with all commits to CVS stopped and no commits to git until the conversion is complete.

When it came to time to migrate I had to use cvs2git and arrange a big-bang cutover, which I did during two consecutive days of meetings spent planning the upcoming quarter, which conveniently prevented anyone from having the time to make changes worth committing.

Note: there is another git-cvs on GitHub: git-cvs by ustuehler. As far as I can tell this is entirely different from the one by osamuaoki. Unfortunately I found this one too late to try it out.