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?
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.
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.
\xF0
(\360
) in iso-8859-7 to \xCF\x80
(\317\200
) in UTF-8 adds a byte.Check for the expected size.
And with Git 2.29 (Q4 2020), the pack header created for import is better managed.
See commit 7744a5d, commit 014f144, commit ccb181d (06 Sep 2020) by René Scharfe (rscharfe).
(Merged by Junio C Hamano -- gitster -- in commit 9b80744, 18 Sep 2020)
fast-import: use
write_pack_header()
Signed-off-by: René Scharfe
Call
write_pack_header()
to hash and write a pack header instead of open-coding this function.
This gets rid of duplicate code and of the magic version number 2 -- which has been used here since c90be46abd ("Changed fast-import's pack header creation to use pack.h", 2006-08-16, Git v1.5.0-rc4 -- merge) and in pack.h (again) since 29f049a0c2 (Revert "move pack creation to version 3", 2006-10-14, Git v1.4.3).
Migration from CVS to Git using cvs2svn
Sharing all step for migration CVS to git
1. create directory a cvsProject in anyDirRsync: your cvs repo: 1. $rsync -av CVSUserName@CVSipAdrress:/CVS_Path/ProjectName/* ~/anyDir/ProjectName
2. cd $../cvs2svn-x.x.0 && ./cvs2git --options=cvs2git-example.options
3. $./cvs2git --blobfile=cvs2git-tmp/git-blob.dat \ --dumpfile=cvs2git-tmp/git-dump.dat \ --username=CVS_YOUR_USER_NAME \ /path_of_step(1)/cvsProject
Note: if get any encoding error then add this into above command:"--encoding=ascii --encoding=utf8 --encoding=utf16 --encoding=latin"
4. mkdir newGitRepo && cd newGitRepo 5. git init --bare 6. git fast-import --export-marks=/x.x.x/cvs2svn-2.5.0/cvs2git-tmp/git-marks.dat \wow now you are done, now you can push your repo to git..
Referenece : [link1][2] ,[link2][2]
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
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. In other words, there is some impedance mismatch 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.
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.
Also, you don't need to own the repo with this method, you can for example migrate SourceForge projects that you don't own (you just need the right to checkout, so this works on any public repo).
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
anddump
containing your whole 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.
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.