Re: your mail

From: Jeff King <peff@peff.net>
Date: Oct 13, 2007, 04:07 UTC
Message-ID: <20071013040712.GA27227@coredump.intra.peff.net>
In-Reply-To: <30817A88-4313-4D38-95B0-FEC47C651CB0@mit.edu>

On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:

Show 8 quoted lines

> Now that you mention it, I think the best approach would be to:
> 	
> 	(1) cvsexportcommit
> 	(2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
> 	(3) git cvsimport ..... # and merge
>
> I think this is what you mean; it seems to me that rebasing isn't quite 
> that.

No, I mean rebasing instead of merge. As in, you have a history like this:

    /--C---D  <-- your master
A--B
    \--C'--D' <-- cvsimport merge tip

where "C" and "D" are your commits in git, and C' and D' are pulled in from cvsimport. You want to rebase your work like this:

A--B--C'--D'--C--D

except that git-rebase is smart enough to realize that C == C' and skip it (so it's a "safe" way of moving forward).

> However, this will not preserve more complicated history such as merges
> from another git repository.

Correct. Rebasing doesn't really handle merges, but I assumed you were just making simple commits on top of a cvs master.

> Basically, I want to treat my git repository as the official
> repository; the CVS repo is just their for the old farts to get the
> latest stuff ;-P

Then my suggestion doesn't really work. You might consider using git as the official server and letting the old farts use git-cvsserver.

HTH, -Peff