From: Michael Witten <mfwitten@mit.edu>
Date: Sat, 13 Oct 2007 23:04:52 GMT
Subject: Re: Imports without Tariffs
Message-ID: <814D00AE-B89A-45ED-A500-4643C825D0EB@mit.edu>
In-Reply-To: <20071013075723.GA27533@coredump.intra.peff.net>


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