All I wanted was git-fast-export

All I wanted was git-fast-export

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

Re: All I wanted was git-fast-export

[Johannes Schindelin]

Hi,

On Sat, 9 Feb 2008, Paul Gardiner wrote:

> 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

Re: All I wanted was git-fast-export

[Paul Gardiner]

Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 9 Feb 2008, Paul Gardiner wrote:
> 
>> 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.

Re: All I wanted was git-fast-export

[Johannes Schindelin]

Hi,

On Sat, 9 Feb 2008, Paul Gardiner wrote:

> Johannes Schindelin wrote:
> 
> > On Sat, 9 Feb 2008, Paul Gardiner wrote:
> > 
> > > 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.

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.

Re: All I wanted was git-fast-export

[Paul Gardiner]

Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 9 Feb 2008, Paul Gardiner wrote:
> 
>> Johannes Schindelin wrote:
>>
>>> On Sat, 9 Feb 2008, Paul Gardiner wrote:
>>>
>>>> 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.
> 
> 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?

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

Re: All I wanted was git-fast-export

[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:

> Johannes Schindelin wrote:
> 
> > 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

Re: All I wanted was git-fast-export

[Paul Gardiner]

Johannes Schindelin wrote:
> 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.

Re: All I wanted was git-fast-export

[Paul Gardiner]

Johannes Schindelin wrote:
> 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:
> 
>> Johannes Schindelin wrote:
>>
>>> 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.

Re: All I wanted was git-fast-export

[Paul Gardiner]

Johannes Schindelin wrote:
> 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:
> 
>> Johannes Schindelin wrote:
>>
>>> 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.

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.