Kevin Bracey <kevin@xxxxxxxxx> writes: > At present, either query will show lots of really boring merge commits > of topic branches at the boundary, with 1 INTERESTING parent that > they're TREESAME too, and 1 UNINTERESTING parent that they may or may > not be TREESAME to, depending on how old the base of that topic branch > was. Most such commits are of no relevance to our history > whatsoever. In the case of "--simplify-merges", the fact that they're > UNINTERESTING actually _prevented_ their simplification - if it had > been allowed to follow the UNINTERESTING path back further, it would > have reached an ancestor, and been found redundant. So limiting the > rev-list actually increases the number of merges shown. > > We can lose all those boring commits with these two changes: > > 1) Previously TREESAME was defined as "this commit matches at least 1 > parent". My first patch changes it to "this commit matches all > parents". It should be refined further to "this commit matches all > INTERESTING parents, if it has any, else all (UNINTERESTING) > parents". (Can we word that better?) Note that this fancy rule > collapses to the same straightforward TREESAME check as ever for 0- or > 1-parent commits. > > 2) simplify_merges currently will not simplify commits unless they > have exactly 1 parent. That's not what we want. We only need to > preserve commits that don't have exactly 1 INTERESTING parent. > > Those 2 rules produce the desirable result: if we have a merge commit > with exactly 1 INTERESTING parent it is TREESAME to, it is always > simplified away - any other UNINTERESTING parents it may have did not > affect our code, so we don't care about whether we were TREESAME to > them or not, and as we don't want to see any of the UNINTERESTING > parents themselves, the merge is not worth showing. > > This makes a massive difference on some of my searches, reducing the > total commits shown by a factor of 5 to 10, greatly improving the > signal-to-noise ratio. > > I'll put together a trial patch at the end of the next iteration of > the series that implements this logic. I need to think a bit more - I > think "get_commit_action" needs a similar INTERESTING check for merges > too, to get the same sort of effect without relying on > simplify_merges. Parent rewriting shouldn't necessitate keeping all > merges - only merges with 2+ INTERESTING parents. Everything you wrote above makes tons of sense. One small worry is how this new simplification interacts with the first parent mode. For the purpose of showing the merge commit itself, the second and subsequent parents are treated as "not INTERESTING" in the above discussion, but that should not propagate back to their parents like the normal UNINTERESTING-ness does. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html