Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
A new export is available from git://pike-git.lysator.liu.se/pike-full-20100101
I checked pike-full-20100103, which appears to be newer.
New since the previous export is that I've found and incorporated another historic ulpc repository (ulpc.hubbe), which means that most of the early history of Pike has been recovered.
Where does this ulpc.hubbe fit in? Before the ulpc repository? When I look at your repository, I see 1995/08/09 still as the oldest commit.
ulpc.hubbe is a few weeks newer than the latest commit on ulpc.old. The ulpc repository has been imported as branch E-13 whick branches off from ulpc.hubbe.
The graph looks something like:
/---------0.5 ulpc.old----//ulpc.hubbe--------...---Pike------< ^ \ ---------... | \ulpc--- | There's some history missing here.
The proper graph for the early (missing) history of Pike should probably be something like:
1.0E-100---------1.0E-30-----------1.0E-14--ulpc.hubbe---... \ \ulpc.old---
Some of it is potentially recoverable from the ChangeLog file and old ulpc dists, but I haven't gone that far...
I believe that I've identified most of the renamed files and when they were renamed, so the commit graph should make more sense now.
Nice. If my import from the SVN version was correct, this should match with my import. An automated check between the two git repositories is not so difficult and actually very fast.
Note that the $Id$ markers in pike-full-10100103 have been extracted in -ko mode, so they most likely don't match the SVN repository. This has been fixed in the current converter.
Another issue is that all commits are currently credited to the committer (ie not necessarily the author). I'll try to extract the information from git://pike-git.lysator.liu.se/pike.git.
The above is still on the todo.
Could it be that this is fixed in the 103 version I just checked?
No, it's still on the todo.
With respect to the too-clever branche/splitting merging, I see that around certain commits the same problem occurs as you discussed earlier around the repository splits. Case in point, around label v7.8.350 there is an artificial "branch loop", and looking back through history I see it again at v7.8.336, and probably throughout the entire repository. Obviously these commits were not splitting off to another branch and then remerging in the next commit. I suggest you change your heuristics to avoid splitting at those (and many other) points, and thus leave the history linearly (as it originally is in CVS at those points).
No, those are actually proper splits. They have typically been casued by the build system running in parallel with someone committing stuff. They are (in the general case) also neccessary to keep the tags on the correct versions of files.
With regard to the ID: and rev: fields at the bottom: it is likely the best solution to keep track of what went where. If it can be trimmed down, that would be great, but if not, it's something which is workable.
The ID field is there for debug purposes. The Rev field is intended to be kept, since the alternative would be add an excessive amount of tags...
In order to incorporate the cherry-pick information (which was incorrectly encoded as additional parents in my import), I suggest we include one or more "Original-patch" fields at the very bottom of the commit field. The information which should go in there, can be extracted from my import repository, since most references in there were already handpicked by me/mast/you.
This should be possible to add.
The import repository I made should be around 50MB, yours is around 150MB. It looks like it still contains a lot of extra garbage.
The main reason is probably that it's a raw repository as generated by git-fast-import. The git-fast-import manual recommends running git-repack -f --window=50 on the repository afterwards.
I'm not sure if your import generates even more stray tags/branches.
Currently I keep all tags and branches except some of the tags generated by cvs import.
It would probably be desirable to trim/organise your import so that it ends up with the same tags and branches as mine (in addition to those which are the result of any extra ulpc.hubbe repository, of course). -- Sincerely, Stephen R. van den Berg.