There are three different tools that allege to do it. They all suck. I have been editing RCS files by hand, with a paper clip and a nine volt battery. Oh, the indignity.<jwz:~/www/> git whatchanged index.html | tail -8
commit a18bb7a908d0dbe4 9d9fe383 d4d24301 99aa0880
Author: Jamie Zawinski <jwz@jwz.org>
Date: Thu Oct 13 19:10:38 1994 -0700
Initial revision
:000000 100644 0000000... c28db08... A index.html
"Look, Ben! All of man's past glory -- in one large SAND PIT!"
My vcs migration consultant friend tells me you probably wanna go CVS -> Subversion -> Git, even though that sounds totally loathsome.
Specifically, he says: "The CVS to Subversion tools got as good as they needed to be a long time ago, and the Subversion to Git tools are pretty excellent, but not that many people needed CVS to Git so those kind of suck." Anyway, good luck.
That would be one of the three ways that suck.
You need an intern in the worst way. Some unscrupulous wretch (read: me) has a mirror of your youtube scripts on github.
I see ... new blog posts in your future.
We migrated to git from SVN a few month ago at work, and, seriously, the command-line interface? It's like it was designed by Linux kernel developers or something.
The very best part of this post is the prospect those future posts.
The seemingly random hexadecimal strings strewn all around are actually a saving grace in this ... particular case.
I attest that some of us are for more than a short while longer hanging onto the use of CVS.
I used
rcsuntil one day it started truncating files to exactly 65536 bytes. Sucks when all your backups perfectly reproduce a corrupted repository. Git has its own charms: it sometimes leaves chicken tracks (>>>) all over your source code for the compiler to find, but it's loads better than RCS.The "chicken tracks" mean you are a Bad Person. Specifically one who doesn't truly believe the revision control system when it tells you there was a conflict which needs manual resolution, and who thus doesn't actually go through manually resolving aforesaid conflicts. The chicken tracks are the default way of showing where the conflict is (git is also quite happy to let you use a 3rd party graphical merge tool to do this stuff instead if you prefer).
It is tempting, at least for C, Java, etc. to add a commit hook rule which rejects commits that try to add chicken tracks because they will nearly always mean the idiot who landed that commit was asleep at the wheel.
Hmm...based on what you described, it makes sense now. I reread the documentation on merge conflicts; it seems I caused a merge conflict with a younger version of myself due to an accident with a time machine. Sorted now...thanks!
You might want to look at http://www.catb.org/esr/reposurgeon/
I just did this a couple months ago myself. Using hints online and svn2git worked pretty well. Then I did what apparently many have done and wrote my own rcs2git script that gets a lot of use. I did my own that converts entire directory trees of files in and not in RCS and does things like preserves files that were deleted (only the ,v copy left in RCS path) and git rms it to duplicate the same situation of keeping the history but leaving the file deleted.
Err... Make that cvs2git from cvs2svn: http://cvs2svn.tigris.org/cvs2git.html
I seem to be gradually converting from RCS to Mercurial.
Have you seen this? "Quite simply, Mercurial is better at merging than Git."
And Betamax is superior to VHS.
And has had a long and prosperous life in the television industry.
So, Eric Raymond's "Reposurgeon" claims to do this work. It has flaws, but ESR actively asks people to help him fix them, unlike the authors of the other tools out there right now, so if you have trouble, he will very likely take your repo as a test case for something he needs to improve. It might be worth trying -- doubtless you'll not be happy with the first attempt, but it is entirely possible that within a couple of days he might have it doing what you need.
Re: Jef's comment on mercurial, there is little question in my mind that mercurial is more user friendly, but sadly at this point the whole world has gone git, and the available selection of tools for git is thus much richer. In an ideal world I'd wave a wand and make hg win instead of git, but you live in the world you have, not the one you want.
Well, we can wave that wand and use hg on our own projects. Which I do. I don't see the downside.
I was sure that bazaar was the future about the same time Canonical decided bundling spyware was an integral part of their business plan.
That is my favorite comic book series, thank you for reminding me that it's time to look again to see that I can't afford to buy a copy of that piece of my past :-)
Good luck. At least you haven't been using SCCS or Clearcase.
I actually use aliases/scripts that mimic the SCCS commands, rather than learning new commands for each new system.
Old guy alert!
OpenBSD still uses CVS as our main repository. However some developers prefer to use git, for their local trees.
We use https://github.com/ustuehler/git-cvs to convert our tree. It is able to convert from the same source, and create the exact same git repository (including hashes and timestamps) every time.