Skip to contentSkip to conversation

All I wanted was git-fast-export

DISCUSSION Paul Gardiner 2 participants 9 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

With your kind help, I've been able to convert a cvs repository to git, but the last several years commits start with a line saying "Summary;" :-( I thought it might not be hard to put a filter between git-fast-export and git-fast-import to sort it out. Turns out though SuSE 10.3 has an old version of git with git-fast-export missing.

I thought I'd try building git-1.5.4-1.src.rpm. Resolved most of the dependencies, but I'm stuck with expat-devel and perl(Error).

I installed Error-0.17012, but that seems to be the wrong perl(Error). Anybody know where I can find the correct one?

SuSE 10.3 seems to have expat, but not expat-devel. I've found expat-devel-2.0.1-4.i386.rpm, but that needs expat-2.0.1-4, and SuSE 10.3 has expat-2.0.1-24. I can't find expat-devel-2.0.1.24 anywhere.

I could, I guess, replace my current expat-2.0.1-24 with expat-2.0.1-4, but I don't know how to check my systems dependencies up front to see if that would be safe.

Any ideas, anyone?

P.

#1 lore raw

Hi,

Quoted 5 lines · Paul Gardiner

With your kind help, I've been able to convert a cvs repository to git, but the last several years commits start with a line saying "Summary;" :-( I thought it might not be hard to put a filter between git-fast-export and git-fast-import to sort it out.

The better tool for this should be filter-branch.

Hth,
Dscho

#2 lore raw
Quoted 11 lines · Johannes Schindelin

Hi,

Quoted 5 lines · Paul Gardiner

With your kind help, I've been able to convert a cvs repository to git, but the last several years commits start with a line saying "Summary;" :-( I thought it might not be hard to put a filter between git-fast-export and git-fast-import to sort it out.

The better tool for this should be filter-branch.

filter-branch does look to be brilliant for this sort of thing, but I don't think I can use it in my case. The git repository in question is a mirror of a live cvs repository, which I need to keep synced up. What I was thinking was to repeatedly do:

cvs rep => git rep => tidied git rep

using fromcvs/togit for the first step, and git-fast-export/git-fast-import for the second. It doesn't look to be the case that filter-branch can be used with the source and target repositories being different, and if I tried having one git repository that I applied tidying to, then I don't think the syncing process would work afterwards... or would it? Do you thing that changing commit messages would mess up subsequent syncing? I guess I could try it and see.

I think I need git 1.5.4 either way, and I still haven't found a way to get that installed under SuSE 10.3

P.

#3 lore raw

Hi,

Quoted 9 lines · Paul Gardiner
Quoted 7 lines · Johannes Schindelin
Quoted 4 lines · Paul Gardiner

With your kind help, I've been able to convert a cvs repository to git, but the last several years commits start with a line saying "Summary;" :-( I thought it might not be hard to put a filter between git-fast-export and git-fast-import to sort it out.

Quoted 4 lines
Quoted 1 line

The better tool for this should be filter-branch.

filter-branch does look to be brilliant for this sort of thing, but I don't think I can use it in my case.

I beg to differ. filter-branch does exactly the same as the fast-export | filter | fast-import you prosed does: it rewrites history.

The thing is, filter-branch was _written for this purpose_. So if you know what commit you rewrote last, you can make the process faster/safer by issuing

	$ git filter-branch --msg-filter="<blabla>" <old-commit>..master

There's also a further upside to filter-branch: at least until recently, it did not use any special features of newer git, but could be extracted (e.g. via gitweb) and used with older git (any git >= 1.5.3 should do, maybe even older ones).

Hth,
Dscho

P.S.: but you seem to be dead-set to upgrade. No problem for me: just go ahead and do what you must.

#4 lore raw
Quoted 10 lines · Johannes Schindelin

Hi,

Quoted 6 lines · Paul Gardiner
Quoted 4 lines · Johannes Schindelin
Quoted 1 line · Paul Gardiner

With your kind help, I've been able to convert a cvs repository to git, but the last several years commits start with a line saying "Summary;" :-( I thought it might not be hard to put a filter between git-fast-export and git-fast-import to sort it out.

The better tool for this should be filter-branch.

Quoted 8 lines
Quoted 2 lines

filter-branch does look to be brilliant for this sort of thing, but I don't think I can use it in my case.

I beg to differ. filter-branch does exactly the same as the fast-export | filter | fast-import you prosed does: it rewrites history.

The thing is, filter-branch was _written for this purpose_. So if you know what commit you rewrote last, you can make the process faster/safer by issuing

	$ git filter-branch --msg-filter="<blabla>" <old-commit>..master

That does look just what I need, but did you see the reason I thought I couldn't use it? I need to repeatedly sync the git repository from a live cvs repository, and repeatedly filter the new commit messages. I'd imagined that filtering the commit messages will mess up subsequent syncing. That's why I thought I'd need a chaing of repositories

cvs => git => tiedied git

What do you think?

Quoted 6 lines

There's also a further upside to filter-branch: at least until recently, it did not use any special features of newer git, but could be extracted (e.g. via gitweb) and used with older git (any git >= 1.5.3 should do, maybe even older ones).

Hth,
Dscho

P.S.: but you seem to be dead-set to upgrade. No problem for me: just go ahead and do what you must.

God no, not if I can help it. I've been performing surgery on my packages over the last couple of days, and I'm sure the whole system is going to fall over any minute. I'd love to be able to use the version I have. It's 1.5.2.4 Is filter-branch likely to work with that?

P.

#5 lore raw

Hi,

[please do not look the other way when you respond to me, i.e. do not cull me from the Cc: list. Thankyouverymuch]

Quoted 11 lines · Paul Gardiner
Quoted 5 lines · Johannes Schindelin

The thing is, filter-branch was _written for this purpose_. So if you know what commit you rewrote last, you can make the process faster/safer by issuing

	$ git filter-branch --msg-filter="<blabla>" <old-commit>..master

That does look just what I need, but did you see the reason I thought I couldn't use it? I need to repeatedly sync the git repository from a live cvs repository, and repeatedly filter the new commit messages.

Oh, I thought you saw why I put in that "<old-commit>...". You do not really need it, as filter-branch will come up with the _same_ commit hashes, unless _something_ was changed.

IOW if you have only commits without that "Summary: " prefix, the filter-branch call will be a (not so cheap) no-op.

But of course, I meant to suggest (admittedly, in a very short short-hand) that you use "git filter-branch ... origin@{1}..origin" after cvsimport.

Hth,
Dscho

#6 lore raw
Quoted 1 line · Johannes Schindelin

But of course, I meant to suggest (admittedly, in a very short short-hand) that you use "git filter-branch ... origin@{1}..origin" after cvsimport.

Sorry to be a bit thick, but I'm very new to git. Can you spell it out for me? Where's that going to get the branch from? Where will the rewritten one end up? And where's the backup old versions of what is rewritten going to end up?

It looks very clever, like it might be a way of accessing filtering one repository into another, but I haven't quite twigged how this all works yet.

P.

#7 lore raw
In reply to Johannes Schindelin
Quoted 6 lines · Johannes Schindelin

Hi,

[please do not look the other way when you respond to me, i.e. do not cull me from the Cc: list. Thankyouverymuch]

On Sun, 10 Feb 2008, Paul Gardiner wrote:

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines · Johannes Schindelin

The thing is, filter-branch was _written for this purpose_. So if you know what commit you rewrote last, you can make the process faster/safer by issuing

	$ git filter-branch --msg-filter="<blabla>" <old-commit>..master

That does look just what I need, but did you see the reason I thought I couldn't use it? I need to repeatedly sync the git repository from a live cvs repository, and repeatedly filter the new commit messages.

Oh, I thought you saw why I put in that "<old-commit>...". You do not really need it, as filter-branch will come up with the _same_ commit hashes, unless _something_ was changed.

Thanks, that indeed works. Using filter-branch, using just --msg-filter does the job without altering hashes, and fromcvs/togit syncs up ignoring the alteration. My message filter is idempotent, so I can rerun it after every sync (or I might try your suggestion above to make it more efficient).

P.

#8 lore raw
In reply to Johannes Schindelin
Quoted 10 lines · Johannes Schindelin

Hi,

[please do not look the other way when you respond to me, i.e. do not cull me from the Cc: list. Thankyouverymuch]

Quoted 4 lines · Paul Gardiner
Quoted 2 lines · Johannes Schindelin

The thing is, filter-branch was _written for this purpose_. So if you know what commit you rewrote last, you can make the process faster/safer by issuing

Quoted 8 lines
Quoted 2 lines
Quoted 1 line
	$ git filter-branch --msg-filter="<blabla>" <old-commit>..master

That does look just what I need, but did you see the reason I thought I couldn't use it? I need to repeatedly sync the git repository from a live cvs repository, and repeatedly filter the new commit messages.

Oh, I thought you saw why I put in that "<old-commit>...". You do not really need it, as filter-branch will come up with the _same_ commit hashes, unless _something_ was changed.

IOW if you have only commits without that "Summary: " prefix, the filter-branch call will be a (not so cheap) no-op.

But of course, I meant to suggest (admittedly, in a very short short-hand) that you use "git filter-branch ... origin@{1}..origin" after cvsimport.

I'm still struggling a bit to understand ref specs. I'm using --all at the moment, but that's very slow. What I need is to filter the new commits of all branches. Will origin@{1}..origin do that, or does it just affect master?

P.