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.
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.
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?
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).
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.
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.
The import repository I made should be around 50MB, yours is around 150MB. It looks like it still contains a lot of extra garbage. After importing, the following tags are forcefully removed to reduce clutter:
hubbes.tag.before.merge1 hubbes.tag.before.rewriting.compiler msqlmod.1.1pre6 postgres.0.5 start v0.6a1
I also delete the following branches:
Hubbe Image.polygon Infovav heddas.polypatchar hubbes.working.branch kinkie locked.for.mirar nisse nisses-certifikat-hack tags/hubbes.tag.before.merge1 tags/hubbes.tag.before.rewriting.compiler tags/msqlmod.1.1pre6 tags/postgres.0.5 tags/start tags/v0 tags/v0.1 tags/v0.6a1
I'm not sure if your import generates even more stray tags/branches. 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).