threads / discuss / 10262

(unknown)

Subject: (unknown)

## tl;dr

7 messages between Oct 13, 2007 and Oct 14, 2007.

replies: 6people: 2as markdown or json

Michael Witten· Oct 13, 2007, 04:01 UTC · lore

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:
Show 6 quoted lines
> 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· Oct 13, 2007, 04:07 UTC · re: Michael Witten · lore

Re: your mail

On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:
Show 8 quoted lines
> 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· Oct 13, 2007, 04:39 UTC · lore

Re: Imports without Tariffs

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!
Show 6 quoted lines
>> 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.

Show 7 quoted lines
>> 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· Oct 13, 2007, 07:57 UTC · lore

Re: Imports without Tariffs

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· Oct 13, 2007, 23:04 UTC · re: Jeff King · lore

Re: Imports without Tariffs

On 13 Oct 2007, at 3:57:23 AM, Jeff King wrote:
Show 11 quoted lines
> 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?
Show 8 quoted lines
>> 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.
Show 6 quoted lines
> 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· Oct 14, 2007, 16:40 UTC · re: Michael Witten · lore

Re: Imports without Tariffs

On Sat, Oct 13, 2007 at 07:04:52PM -0400, Michael Witten wrote:
Show 6 quoted lines
> 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· Oct 14, 2007, 22:10 UTC · re: Jeff King · lore

Re: Imports without Tariffs

On 14 Oct 2007, at 12:40:01 PM, Jeff King wrote:
Show 6 quoted lines
> 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. ;-)
Show 6 quoted lines
>> 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!

← back to recent threads