On 13 Oct 2007, at 3:57:23 AM, Jeff King wrote:
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?
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.
Do I just submit the patch to this list? How do I know it will be used?
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
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.
It would certainly be more useful than not.
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.
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
-
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
