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

Kevin Bracey [off-list ref] 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.