From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: cvs to git migration - keywords |
Date: | 2010-07-15 06:58:01 |
Message-ID: | 4C3EB179.5080501@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 07/07/2010 08:31 PM, Andrew Dunstan wrote:
> Personally I favor leaving the expanded keywords in what we import, so
> that there's an exact mapping between what's in the final CVS repo and
> what's in the inital git repo, and then removing them entirely. I don't
> see that having old keyword expansions in the historical changesets is a
> bid deal. Nobody is going to base patches on them (I hope).
Sorry for being somewhat late on this discussion.
Another reason keeping the expanded keywords in historic revisions that
hasn't been raised so far is, that they can easily be un-expanded with a
script. But it's a lot harder to do the expansion, once you are on git,
if you once happen to need that info.
Of course, I'd also remove the keywords from every (active?) branch as a
first commit after the import. I'd even favor removing those lines
completely, just as sort of a cleanup commit. And no, that shouldn't
pose any problem with outstanding patches, except you are fiddling with
the tag itself. In which case you deserve to get a conflict. ;-)
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2010-07-15 08:44:26 | Re: Per-column collation, proof of concept |
Previous Message | Richard Huxton | 2010-07-15 05:30:46 | Re: standard_conforming_strings |