[cairo] Confusion of "tor" during cvs->git conversion process

[Carl Worth]

I screwed up.

When we ran the conversion of cairo's cvs history through an import
process we provided it with file that mapped usernames on the cvs
server machine to real names and addresses which it should insert into
the git commit Author field.

Well, I just found that the file I used had the following, very
unfortunate, (though easy to make), error in it:

	tor=Tor Lillqvist <tml at novell.com>

A correct file would have had the following two entries instead:

	tml=Tor Lillqvist <tml at novell.com>
	tor=Tim Rowley <tim.rowley at gmail.com>

The net result is that the current history puts Tor's name almost
everywhere that Tim's should appear. I apologize to both Tim and Tor
for the error.

I'd like to fix this, so I'm open to any suggestions on the best way
to do it.

Rebuilding the entire repository with corrected authorship would be
particularly unpleasant since it would change the names (sha1 hashes)
of all the commits since the first commit with the incorrect
authorship. This wouldn't bee too important for the commits from
before we switched to git since we haven't used those names much at
all. But it would break a lot of things for the commits since the
switch to git, since we've published those hashes a lot:

	* Release announcement for 1.0.4

	* Snapshot announcements for 1.1.2, 1.1.4, 1.1.6

	* Email archives with gitweb URLs

	* Every git clone of cairo that anybody has ever done

Breaking the release announcements and the archives would be an awful
thing to do. And going through the effort to get everyone to switch
their repositories over somehow, would also be a huge pain.

So I want to avoid all of that if possible.

Instead, I think we should be able to just rebuild the history
corresponding to the time for which we were using cvs. Then we can use
git's "graft" mechanism to connect the more recent git-original
history to the newer build of the old, originally-in-cvs history.

I don't see a lot of drawbacks to that approach, except that I don't
know how well the graft approach works. If we do a new clone from a
repository with the graft do we also get a repository with the graft,
or will it chase down the original parent link until the cloner
manually creates the same graft?

(For a bit of background, the graft mechanism allows for an external
association of a parent to an existing commit object, (independent of
the parent link within the commit). This mechanism was originally
invented to graft in linux kernel history that was converted over from
before git existed. As such, the original linux graft was used to
provide a parent to a commit that had no parent. This is obviously
different from the graft we would need here which would be changing a
parent.)

If we do do this rebuilding we might also take a look at how the
cvs->git import failed in any spots. In the original conversion, I
ensured that the code matched between cvs and git for all tags
originally in the cvs tree. But, there do appear to be failures that
that checking did not catch. For example, Tim found the following
commit which has a commit message and authorship totally inconsistent
with the original change to the ChangeLog file:

http://gitweb.cairographics.org/?p=cairo;a=commit;h=b913a81c3482f4dc8bc452d91bfaf64b416523f3

When we did the original import, Keith hadn't yet written his parsecvs
tool, so now that we have that we might be able to use it to do a
better job of handling the import process.

Anyway, if anybody wants to look into this and start experimenting
with parsecvs and git grafts, then that would be great. I wish we were
as free from cvs as I thought we were, but it looks like we might have
to delve once again into the cairo history stored in that nightmare
system.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060522/bb5d637f/attachment.pgp