09:36:03 < wgrant> kfogel: Your /Contributions script has become rather confused with the db-stable=>devel merge.
09:36:26 < kfogel> wgrant: oh really?
09:36:27 * kfogel looks
09:36:45 < wgrant> kfogel: See r9571
09:36:57 < wgrant> Not sure of a good way to fix this.
09:36:59 < kfogel> ACK
09:37:01 < kfogel> sigh
09:37:27 < wgrant> You sort of have to run over both devel and db-devel, only counting real top-level merges.
09:37:32 < kfogel> wgrant: right, because it finds any top-level rev that includes a rev somewhere beneath it by that contributor.
09:37:40 < kfogel> wgrant: that was not a response to what you said
09:37:46 < kfogel> wgrant: just typing at same time
09:39:52 < kfogel> wgrant: yeah, I think LogExCons:log_revision() is where the logic needs to be tweaked.
09:41:40 < kfogel> wgrant: hmmmm, this is deeper than that.
09:41:48 < wgrant> kfogel: Is it?
09:42:26 < kfogel> wgrant: well, I just mean that first of all, running across two branches instead of one is going to change things a bit. It's not rocket science, but it's
not a fix localized to just that one method either.
09:43:14 < kfogel> I think your solution is basically right. I'm worried what will happen when there's a db-devel -> devel merge, though. We'll still need a way to
distinguish a "real" top-level rev from that kind of merge rev.
09:43:49 < wgrant> kfogel: Perhaps just run across db-devel, and be a little bit special when both the parent and grandparent are PQM revisions.
09:45:16 < wgrant> Where by parent and grandparent I mean the other way around.
09:45:31 < wgrant> The two subsequent children, that is.
Fixed in stable r10496 <http://