Handling of branch deletion and recreation
I'm not entirely sure whether this is a reposurgeon issue or a gcc-conversion issue, but I'm treating it as a reposurgeon issue on the basis of a deliberate change made by Eric to the gcc-conversion code.
In the GCC history, /trunk was accidentally deleted three times, each time being recreated as a copy of a previous revision of itself: deleted at r130803 then recreated r130805; deleted r138077 then recreated r138078; deleted r184996 then recreated r184997.
gcc-conversion formerly had code to hide those commits. It's now commented out (by Eric), with a comment "Should no longer be needed due to branch recoloring.".
But in my latest conversion, the most recent trunk creation (Legacy-ID: 184997) appears as a merge commit, creating a great many files. It's fine if such a trunk creation appears as a null commit with no file changes; it's not fine if it appears as a merge commit, or as recreating deleted files, as that messes up "git blame" (which is how I noticed the issue). Furthermore, the parents of that merge commit seem wrong. One of them corresponds to Legacy-ID: 184988, which is a trunk commit but not the most recent one from which the recreation was copied (the copy was from /trunk:184995, and the most recent trunk commit as of that revision was r184990). The other corresponds to Legacy-ID: 184014, a commit that appears to have ended up on the "root" branch. Furthermore, the diffs relative to the first parent are much bigger than would be expected; they create a load of files that should already have been present in that first parent. So even if gcc-conversion should be doing things differently, these messed up contents look like a reposurgeon bug somewhere, though that one may be a separate bug from the issue with wrong parents of the trunk-recreation commit.