On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
