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
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.
Ok. Excellent. Just make sure then that the build system is using the second-parent-slot, and the regular commits use the first-parent-slot (so that --first-parent on git commands merely yields proper commits).
This will typically be the case, since it does a best-match tag reachability analysis of the parents of the merge node, which will prefer the parent with no tags of its own. If this fails, it will fall back to selecting the most recent parent, which again typically will not be the commit from the build system, since if it was, the split wouldn't have happened.
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 can't seem to get git-repack to do anything; it just says "Nothing new to pack.".