On Sat, Oct 13, 2007 at 12:30:09AM -0400, Michael Witten wrote: >> except that git-rebase is smart enough to realize that C == C' and skip >> it (so it's a "safe" way of moving forward). > > This is good to know! The documentation should mention this case! Yes, it probably should. Can you submit a patch describing the behavior where you think it ought to go? > Basically, the imported cvs history should be treated like > a remote that's being tracked. It seems like the solution > I proposed kind of does this and would work for other SCM > imports too. 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 again, and your git->cvs->git merge really _will_ be a fastforward. > Unfortunately, they are the ones running the servers; I have to do my > git work behind the scenes. 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 - 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
