Reposurgeon Defeats All Monsters | Hacker News Reader

Reposurgeon Defeats All Monsters

esr.ibiblio.org

21 pointszimpenfish7 comments

Ugh. I once tried using reposurgeon to fix up a repository history after conversion from CVS, where the first couple of checkins were converted into individual commits for each file. The thing was unusable. After hours of trying to understand the bizarre, underspecified DSL, I couldn't find anything that would let me combine a number of sets of commits and define parent relationships between them. There was some command that launched Python REPL, but when I tried it, the program crashed (I don't remember why exactly, but I think it was because of a typo in the code). I don't understand why a DSL was even necessary in the first place. The whole thing could have just been a library.

I ended up writing my own parser for git fast-import streams from scratch; it was easier than dealing with this mess. What a shame this domain hasn't been touched by someone more competent than ESR.

Your story is completely opposite from my experience: reposurgeon resolved my cvs-git import problem without needing much babysitting, if any.

>by someone more competent than ESR.

And yet your own HN profile advises: "Please do not be disrespectful toward others."

Judging by the last paragraph, he positions himself below ESR' competency :)

Don't we all.

I'm always bit sceptical of "our rewrite in new language is quicker" stories. If I were to rewrite something in the same language as v1 t would probably be quicker.

Actually that's not true, I'd probably get bored and then just ry to get the damn thing working as well as v1 used to and then go on holiday without optimising.

Thing is, it wasn't a rewrite. I deliberately did as dumb and literal a translation as I could because I feared that if I tried to change the code wile translating it the complexity of the job would spiral out of control.

One reason this is clear in my mind is that we did do a lot of serious optimization after the dumb straight-line translation first passed my test suite. Because we could; Go's profiling tools are much, much better than Python's - in fact they're better than for any other language I've used.

Interestingly, one of the early results from profiling was t - once we got rid of one O(n2) that only blew up on stupidly large repositories like GCC's - the profile didn't show any of the usual kind of 80/20 hotspots. The biggest box was GC - the Python code had already been really well optimized. Er, who knew?

That makes this a particularly good language vs. language comparison.

Reply on news.ycombinator.com