Re: [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges

> 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.