Yes, it probably should. Can you submit a patch describing the behavior
I think it's an interesting avenue to pursue, though I would worry a

little about robustness. I like the fact that after rebasing, the

commits have done a complete git->cvs->git loop and look identical, so I

am sure everything made it through intact. But perhaps I'm just being

paranoid.
As an alternate idea, why not try to have the CVS commit contain all

information necessary to create a particular git commit. IOW, describe

all of the data that goes into the commit hash as textual comments in

the CVS commit (committer name/time, author name/time). And then

theoretically git-cvsimport can reconstruct the exact same commits
I've been in the same boat, and just used the rebase trick I described.

Of course it was a very tiny project, so I didn't mind losing some of

the full power of git.
-Peff

-

I can make a patch, but at the moment I'm swamped and I don't want to

think

about doing that.
I'll get around to it eventually, I hope.
Frankly, I don't know how robust my idea is either, but it's simple

enough not to have many problems lurking in the shadows.
I considered this too, but this exposes what we're doing. We don't

want the old farts to wonder what all these hash thingies are.
Michael Witten

-

Yes, send a patch to the list and to Junio (the maintainer).  See
Heh. I like the idea of git secretly infiltrating institutions,

replacing CVS unbeknownst to management. It was the same for Linux in

the mid-90's ("our mail server is running on what!?").
-Peff

-

Replace CVS or Bust!

-