Policy decisions and cosmetic issues remaining for the git conversion - Mailing list pgsql-hackers

This is an attempt to sum up the open issues remaining before we can
make another try at converting our source code to git.

* As I noted previously, up till about 2003 we were quite haphazard about
applying CVS tags to identify the points where releases were made.  Should
we try to clean that up?  I think there is a stronger case for moving the
three existing misleading tags than for creating new tags matching the
releases that have none.  Maybe nobody will ever care about any of them,
but if we are trying to create a good historical record it might be
appropriate to do it now while we have the information in mind.

* If we do the above, should it be done in the existing CVS repository
or just as part of the conversion to git?  (I suspect it'd be a lot easier
in git.)  Similarly, ought we to fix the now-known tagging inconsistencies
in the CVS repository, or just leave it for the conversion to deal with?

* There are a number of partial tags (tags applied to just a subset of
files) in the CVS repository: "MANUAL_1_0" and "SUPPORT" seem to have been
applied to only documentation-related files, and "creation" and
"Release-1-6-0" were applied only to src/interfaces/perl5/.  I find the
latter two particularly misleading since they have nothing to do with
either creation of the whole project or a "release 1.6" of the whole
project.  These partial tags don't translate very well to git, either.
I'm inclined to propose dropping all four.

* The REL8_0_0 branch needs to be downgraded to a tag, as previously
discussed.

* There are several things we should do to make the manufactured commits
less ugly, assuming we can't get rid of them entirely:
** Blame them on a nonexistent committer, probably "cvs2git" itself.
** If we do that, I'm inclined to also blame the inserted dead .0  revisions on cvs2git.  Right now I copied-and-pasted
thecommitter info  from the mainline commit they inherit from, which is not very relevant.
 
** Make the manufactured-commit log messages say cvs2git not cvs2svn.
** Perhaps reword the log messages for the inserted dead .0 revisions?  I didn't spend any time thinking about what
theyshould say.
 

* A more aggressive answer would be to collapse the manufactured commits
for back-branch additions out of the history entirely, as was discussed
briefly earlier.  I'm not sure this is worth the trouble/risk.

* There are a couple of manufactured commits that we could just delete,
I think: the ones to create the Release_2_0 and Release_2_0_0 tags.  The
tags should be reapplied to the chronologically preceding mainline commits
instead.  This is just cosmetic but we may as well do it.  I still think
there's a cvs2git bug underlying those.

Comments?
        regards, tom lane