Re: Problem with git-cvsimport
- From
- Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no>
- Date
- Oct 9, 2007, 19:41 UTC
- Message-ID
- <47065A5D-D170-4D11-A802-85376F97F8D2@orakel.ntnu.no>
- In-Reply-To
- <470B8049.1090308@samba.org>
On 9. okt.. 2007, at 15.21, Gerald (Jerry) Carter wrote:
> I would actually plug using cvs2svn to convert directly to git. > See this thread for Michael's original announcement. > > http://marc.info/?l=git&m=118592701426175&w=2
Seconded! I've tried git-cvsimport, parsecvs, fromcvs, and cvs2svn on my employer's many large CVS modules, and cvs2svn is the only one that has never mangled an import.
That said, it is a work in progress, so there are some caveats:
* Setting up the direct conversion to git is more work than it should (and probably will, eventually) be.
* There is no support for incremental importing, and git-cvsimport _will_ mess up your git repository sooner or later if you try to use it for subsequent incremental imports.
* Tags each get a branch with a single commit, with the actual tag pointing to that commit. This makes it harder than necessary to figure out what the history looks like; gitk's default view won't show any tags, for example, since it only shows the master branch and not the single-commit tag branches.
* Branches all get a useless commit at their branch point. All branches from the main branch appear to be merged from the vendor branch (ie, the useless commit has the vendor branch as an extra parent), which might make sense to someone who knows what the vendor branch is for, but makes no sense to me. This combined with the previous point makes "gitk --all" look needlessly spaghetti-like if you have a slightly complicated CVS history.
To sum up, cvs2svn gets the important stuff right, but has some sharp corners you need to watch so you don't put an eye out.
Eyvind Bernhardsen