Migrate from CVS to Git without losing history

Question

I need to know if there is a way to migrate my code from CVS source control to Git?

If yes, what about my history of commits?

Answer 1

I've not personally done a conversion from CVS to Git, but I believe Eric Raymond's cvs-fast-export is the tool to use. He has the man page posted here. cvsps is another tool maintained by Eric, but it has recently been deprecated in favor of cvs-fast-export. cvs2git is another tool which is built on some of the same machinery as cvs2svn. The latter was extremely adept, and so I have high hopes that cvs2git is equally good.

One thing to note: CVS is a pretty broken RCS. It's possible that it can have content that can't be reflected exactly in Git. IOW, there is some mismatch impedance there, but the tools try very hard to preserve as much as possible. Make sure to check your conversion and that you're happy with the results. You may need to fixup part of the Git history to get something more acceptable, but I doubt you'll need to.

Answer 2

Here is the process I used to migrate a SourceForge CVS repo to Git using cvs2git (latest stable release is here, but IIRC I used the github dev version), which works on both Windows and Linux without any compilation required since it's just Python:

How to import from sourceforge CVS to git.
First, you need to download/checkout the cvs repo with the whole history (not just checkout the HEAD/Trunk):

rsync -av rsync://PROJECT.cvs.sourceforge.net/cvsroot/PROJECT/\* cvs  

then use cvs2git (python script, works on all platforms, no compilation needed):

python cvs2git --blobfile="blob.dat" --dumpfile="dump.dat" --username="username_to_access_repo" --options=cvs2git.options --fallback-encoding utf-8 cvs  

this should have generated two files blob and dump containing all your cvs history. You can open them in a text editor to check that the content seems correct.

then initialize your git repo inside another folder:

mkdir gitexport/
cd gitexport
git init  

then load up the exported cvs history onto git:

cat ../{blob,dump}.dat | git fast-import  

and then place the git commit cursor at the end of history:

git reset --hard  

finally and optionally, you can push to your remote git repository:

git push -u origin master  

of course you need before to git remote add origin https://your_repo_url

Note: cvs2git.options is a JSON formatted configuration file for cvs2git where you can specify transforms for various things like author names (so that their nicknames will be automagically transformed to their full name after import). See the documentation here or the included example options file.

Also you don't need to own the repo with this method, you can migrate SourceForge projects that you don't own (you just need the right to checkout, so this works on any public repo).

Answer 3

You can use git-cvsimport to import your CVS repository into Git. By default, this will check out every revision, giving you a relatively complete history.

Depending on your operating system, you may need to install support for this separately. For example, on an Ubuntu machine you would need the git-cvs package.

This answer goes into more detail.

Answer 4

I've used recently (2016) reposurgeon of Eric Raymond to import a CVS repo from sourceforge to git. I was very pleasantly surprised and it worked very well. After past experiences with cvs2svn and other tools, I recommend without hesitation reposurgeon for this kind of tasks.

Eric has posted a straightforward migration guide here

Answer 5

In order to clone a project from sourceforge to github I performed the following steps.

PROJECT=some_sourceforge_project_name
GITUSER=rubo77
rsync -av rsync://a.cvs.sourceforge.net/cvsroot/$PROJECT/\* cvs
svn export --username=guest http://cvs2svn.tigris.org/svn/cvs2svn/trunk cvs2svn-trunk
cp ./cvs2svn-trunk/cvs2git-example.options ./cvs2git.options
vim cvs2git.options # edit run_options.set_project
cvs2svn-trunk/cvs2git --options=cvs2git.options --fallback-encoding utf-8

create an empty git at https://github.com/$GITUSER/$PROJECT.git

git clone git@github.com:$GITUSER/$PROJECT.git $PROJECT-github
cd $PROJECT-github
cat ../cvs2git-tmp/git-{blob,dump}.dat | git fast-import
git log
git reset --hard
git push

Answer 6

gaborous's answer uses git fast-import, which could fails on log message not encoded in UTF-8.

That will work better with Git 2.23 (Q2 2019): The "git fast-export/import" pair has been taught to handle commits with log messages in encoding other than UTF-8 better.

See commit e80001f, commit 57a8be2, commit ccbfc96, commit 3edfcc6, commit 32615ce (14 May 2019) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 66dc7b6, 13 Jun 2019)}

fast-export: do automatic reencoding of commit messages only if requested

Automatic re-encoding of commit messages (and dropping of the encoding header) hurts attempts to do reversible history rewrites (e.g. sha1sum <-> sha256sum transitions, some subtree rewrites), and seems inconsistent with the general principle followed elsewhere in fast-export of requiring explicit user requests to modify the output (e.g. --signed-tags=strip, --tag-of-filtered-object=rewrite).
Add a --reencode flag that the user can use to specify, and like other fast-export flags, default it to 'abort'.

That means the Documentation/git-fast-export now includes:

 --reencode=(yes|no|abort)::

Specify how to handle encoding header in commit objects.

• When asking to 'abort' (which is the default), this program will die when encountering such a commit object.
• With 'yes', the commit message will be reencoded into UTF-8.
• With 'no', the original encoding will be preserved.

fast-export: avoid stripping encoding header if we cannot reencode

When fast-export encounters a commit with an 'encoding' header, it tries to reencode in UTF-8 and then drops the encoding header.
However, if it fails to reencode in UTF-8 because e.g. one of the characters in the commit message was invalid in the old encoding, then we need to retain the original encoding or otherwise we lose information needed to understand all the other (valid) characters in the original commit message.

fast-import: support 'encoding' commit header

Since git supports commit messages with an encoding other than UTF-8, allow fast-import to import such commits.
This may be useful for folks who do not want to reencode commit messages from an external system, and may also be useful to achieve reversible history rewrites (e.g. sha1sum <-> sha256sum transitions or subtree work) with Git repositories that have used specialized encodings in their commit history.

The Documentation/git-fast-import now includes:

encoding`

The optional encoding command indicates the encoding of the commit message.
Most commits are UTF-8 and the encoding is omitted, but this allows importing commit messages into git without first reencoding them.

---

To see that test which uses an author with non-ascii characters in the name, but no special commit message.
It does check that the reencoding into UTF-8 worked, by checking its size:

The commit object, if not re-encoded, would be 240 bytes.

• Removing the "encoding iso-8859-7\n" header drops 20 bytes.
• Re-encoding the Pi character π from \xF0 (\360) in iso-8859-7 to \xCF\x80 (\317\200) in UTF-8 adds a byte.

Check for the expected size.