Re: cvs to git migration - keywords - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: cvs to git migration - keywords
Date
Msg-id AANLkTinvUKNYn6Ujep7X5uac6CtDRmK8P4GxbOE1gaOh@mail.gmail.com
Whole thread Raw
In response to Re: cvs to git migration - keywords  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: cvs to git migration - keywords
List pgsql-hackers
On 7/7/10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>  > So what happens right now using the existing git repository is that
>  > the $PostgeSQL$ tags are there, but they're unexpanded.  They just say
>  > $PostgreSQL$ rather than $PostgreSQL: tgl blah blah$.
>
>
> Really?  All of them?  Seems like that would have taken some intentional
>  processing somewhere.

AFAIK that's what CVS actually keeps in repo, it expands keywords
when writing files out.

>  If we could make the conversion work like that (rather than removing the
>  whole line) it would negate my line-number-change argument, which might
>  mean that files pulled from the repository would be "close enough" to
>  their actual historical form that no one would mind.  It's still a
>  judgment call though.  On balance I think I'd rather adopt the simple
>  rule that historical file states in the git repository should match what
>  you would have gotten from the cvs repository.

I would prefer that the diffs should match what CVS gives / what got
committed.

Sanity-checking by comparing CVS checkout with GIT checkout with
unexpanded keywords can be scripted easily enough, and is one-time
affair.

But humans want to review old diffs quite more frequently...

+1 keeping keywords, but unexpanded.

-- 
marko


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Per-column collation, proof of concept
Next
From: Simon Riggs
Date:
Subject: Re: SHOW TABLES