# (unknown)

7 messages from 2007-10-13 to 2007-10-14. Participants: Michael Witten, Jeff King.
Thread: https://gitlist.dev/t/10262

## Michael Witten, 2007-10-13 04:01

Subject: (unknown)
Message-ID: <30817A88-4313-4D38-95B0-FEC47C651CB0@mit.edu>
URL: https://gitlist.dev/e/30817A88-4313-4D38-95B0-FEC47C651CB0%40mit.edu

```
I apologize if this is received twice.
I did add some comments, though!



On 12 Oct 2007, at 10:49:10 PM, Jeff King wrote:
> You are presumably doing a 'git-pull' on the cvsimport-ed commits. Try
> doing a git-rebase, which will filter out commits which make the same
> changes. Yes, it means throwing away your original commits, but the  
> new
> ones should be morally equivalent (and are now the "official" upstream
> of the CVS repository).

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.

However, this will not preserve more complicated history such as merges
from another git repository.

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

Thanks!

Michael

PS
Please send me other opinions.

```

## Jeff King, 2007-10-13 04:07

Subject: Re: your mail
Message-ID: <20071013040712.GA27227@coredump.intra.peff.net>
URL: https://gitlist.dev/e/20071013040712.GA27227%40coredump.intra.peff.net
In-Reply-To: <30817A88-4313-4D38-95B0-FEC47C651CB0@mit.edu>

```
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

```

## Michael Witten, 2007-10-13 04:39

Subject: Re: Imports without Tariffs
Message-ID: <8FCAF2B7-00A1-4AD1-A14E-CA88B5A84B89@mit.edu>
URL: https://gitlist.dev/e/8FCAF2B7-00A1-4AD1-A14E-CA88B5A84B89%40mit.edu
In-Reply-To: <1240801C-F4CC-4290-8C3D-2038F1957DF3@MIT.EDU>

```
I apologize if you receive this twice.
I have now changed my email client to
use plain text by default.

On 13 Oct 2007, at 12:07:12 AM, Jeff King 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!

>> 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.

Yes, you are quite correct. Your solution will work for me.
However, I think a general solution should be sought out.

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.

>> 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.

Unfortunately, they are the ones running the servers; I have to do my
git work behind the scenes.

Thanks,
Michael

```

## Jeff King, 2007-10-13 07:57

Subject: Re: Imports without Tariffs
Message-ID: <20071013075723.GA27533@coredump.intra.peff.net>
URL: https://gitlist.dev/e/20071013075723.GA27533%40coredump.intra.peff.net
In-Reply-To: <1240801C-F4CC-4290-8C3D-2038F1957DF3@MIT.EDU>

```
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

```

## Michael Witten, 2007-10-13 23:04

Subject: Re: Imports without Tariffs
Message-ID: <814D00AE-B89A-45ED-A500-4643C825D0EB@mit.edu>
URL: https://gitlist.dev/e/814D00AE-B89A-45ED-A500-4643C825D0EB%40mit.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

```

## Jeff King, 2007-10-14 16:40

Subject: Re: Imports without Tariffs
Message-ID: <20071014164001.GC27595@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20071014164001.GC27595%40sigill.intra.peff.net
In-Reply-To: <814D00AE-B89A-45ED-A500-4643C825D0EB@mit.edu>

```
On Sat, Oct 13, 2007 at 07:04:52PM -0400, Michael Witten wrote:

> 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?

Yes, send a patch to the list and to Junio (the maintainer).  See
Documentation/SubmittingPatches for details.

> 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.

Then submit a patch implementing it. :)

>> 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
> 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.

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

```

## Michael Witten, 2007-10-14 22:10

Subject: Re: Imports without Tariffs
Message-ID: <7B69C0EA-A1FB-4133-895E-AE30DBAECC11@MIT.EDU>
URL: https://gitlist.dev/e/7B69C0EA-A1FB-4133-895E-AE30DBAECC11%40MIT.EDU
In-Reply-To: <20071014164001.GC27595@sigill.intra.peff.net>

```
On 14 Oct 2007, at 12:40:01 PM, Jeff King wrote:

> On Sat, Oct 13, 2007 at 07:04:52PM -0400, Michael Witten wrote:
>> Do I just submit the patch to this list? How do I know it will be  
>> used?
>
> Yes, send a patch to the list and to Junio (the maintainer).  See
> Documentation/SubmittingPatches for details.

Indeed! RTFM, as they say. ;-)

>> 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.
>
> Then submit a patch implementing it. :)

Perl. Ugh. I'll see what I can do, though it may take 1.5 weeks.

> 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!?").

:-)

Replace CVS or Bust!

```