Why is git-cvsimport missing one major patchset?

Question

This is a followup to a previous question of mine.

I can look through the output of cvsps (saved in my ~/.cvsps directory) and see a patchset for a major, complicated co

Answer 1

Thanks a lot! I had the same problem and could fix it with your help!

I even found a way to avoid re-running cvsimport from scratch. Simply setting the 'master' and the 'origin' branch to older git commits made cvsimport re-import the patches since that including the missing ones:

find a commit ID older than the missing commits:

git log

make 'origin' point to that commit

git branch -f origin

switch to origin (so that 'master' is not the current HEAD)

git checkout origin

now make 'master' point the older commit as well

git branch -f master origin

switch back to master

git checkout master

now, time is completely rolled back and you can do the cvsimport again, this time properly

git cvsimport ...

Answer 2

I encountered such thing recently - there was a commit in CVS that didn't show up in git after git cvsimport; later commits did (it bit me hard, because I produced nonworking patches afterwards.

However, the fix was simple and stupid - I just reset the cvs/master branch before the missing commit, rerun git cvsimport, and there it was.

Answer 3

Hmm, the good news is that git-cvsimport appears to be written in Perl, and I happen to be a Perl programmer, so maybe I can at least step through this with the Perl debugger to find out what happens during that commit.

For anyone who wants to try this, you'll have to locate the full path to git-cvsimport and feed it to perl (the Perl interpreter) with the -d switch:

perl -d /usr/local/libexec/git-core/git-cvsimport

I haven't gotten all the other options worked out to do this, yet ... I'll need to feed git-cvsimport the output of cvsps directly, I think...

Answer 4

Well, this may be the problem. My git-cvsimport lines look like this:

git cvsimport -p x ...

The -p x is is supposed to pass the -x option to cvsps to tell it to ignore the cached output that it left lying around from previous runs. I thought the main reason to do that was so that the last few patchsets, which might be incomplete, will be thrown out and completed the next time you run. Turns out there may be more issues that it fixes, and this may be one of them.

I learned to run git cvsimport this way from this blog entry, which is currently one of the highest hits on Google for "git cvs." It was only in the process above, where I was trying to run git-cvsimport through the Perl debugger on output from cvsps, that I had to check and see what arguments were really going to cvsps. I learned cvsps was being run like this:

cvsps --norc x --cvs-direct ...

Instead of:

cvsps --norc -x --cvs-direct ...

And I experimentally verified that I get different output from cvsps, with some patchsets missing (I have no idea what the pattern is), when x is passed instead of -x. Thanks to Murphy's law, cvsps doesn't seem to report that this was a problem, and git-cvsimport never sees it.

So anyway, git cvsimport needs to be run like this:

git cvsimport -p -x ...

My previous versions of this repository are completely hosed at this point, but I have been able to force the last of the problem commits into them (some of the earlier commits are missing, though). So I get to go through the four-hour import process one more time, and I'm hoping that will be it!

One last tip: git-cvsimport on Windows doesn't seem to work at all. I got less than 10% of the number of commits, although I did wind up with a tree that resembles the current state of our project. It just seems to be lacking almost all the history...