Re: Report: removing the inconsistencies in our CVS->git conversion

I wrote:
> I had not previously bothered to patch the places where a file was added
> on the branch immediately after being added on the main, but now it
> seems worth doing. That will get us down to a *very* small number of
> manufactured commits in the final version.

Attached is an updated repository.fixups script that inserts dead
revisions in every case where a new file was back-patched into an
existing branch. With that, we are down to a total of nine manufactured
commits, to wit:

* Four that create the partial tags SUPPORT, MANUAL_1_0, creation, and
Release-1-6-0. I think we agreed that we can just drop these tags and
allow their manufactured commits to be garbage-collected.

* Two that create the tags Release_2_0 and Release_2_0_0. I think these
probably represent a cvs2git bug, as there is no apparent reason why it
didn't just apply the tags to the immediately preceding mainline commits
instead. In any case, we can get rid of them by moving the tags to the
appropriate commits manually.

* One that creates the branch REL2_0B. This is caused by a known,
longstanding cvs2git deficiency: it fails to pick the optimal place
to branch from when file deletions are involved. We're just going to
have to live with that, I think; it's a pretty minor infelicity anyway.

* One that creates the partial branch ecpg_big_bison. I think we have
to live with this too. I don't want to drop the branch altogether,
as that would represent a loss of development history. The only other
alternative I can think of is to try to convert it into a full branch,
but I'm unsure what the implications would be of that.

* And lastly, there's a weird manufactured commit that adds a passel of
files on REL7_3_STABLE branch, only to have them deleted again by the
following real commit. This is a result of the fact that the branch
point was moved long after creation, as discussed here:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00127.php
We could maybe try to get rid of both the manufactured commit and
the deletion commit, but I'm inclined not to. The underlying history
is really as dirty as this commit makes it look.

The long and the short of it is that I'm now satisfied with the git
conversion. There is still the issue of adding/adjusting release tags
for ancient releases, but the lack of those is surely not the
conversion's fault.

regards, tom lane

PS: This attachment is text/x-patch instead of text/plain ... does
it come through as an attachment for you, Robert?