Hi Antonio and Derrick! > I think what you really want is --full-history --simplify-merges [1]. This > will show the merges that "fork" the history into parallel tracks where > at least two of them contain interesting commits. It doesn't look like the implementation of --simplify-merges helps much here. That makes its decision on basis of the parents of the commit, which is simple to do as it's information attached freely to each commit. I think the problem here would be figuring out, given any commit, how many of its children are "relevant" commits. > I'm actually working on something that does the opposite---it ignores > the fork point when drawing the graph. (I'm currently dog-fooding a > partial implementation of this.) That's a pretty interesting coincidence :) Just to throw ideas out there, maybe we could attach another commit_list, children, to the commit metadata, so that all this becomes a little easier. But I guess that's be pretty impractical and inefficient. Maybe a more practical (but still pretty unusual) solution would be adding counters to each commit that tell us how many times they have been traversed Through various histories?
