Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?

Hi all,

Is there a method within `git rev-list` to trim side branch merges where the merge's tree is identical to the first parent's commit-tree?

One back-story: In the Git-for Windows repository, the previous releases are 'deadheaded' by merging with the upstream git, and simply taking the upstream's tree unconditionally. The Git-for-Windows `fixes` are then rebased onto that merge.

This does mean that all the fixes keep repeating down the 2nd parent line. So, for example, grep'ing for changes can tricky with so much repeated chaff, but at least all old versions are directly in the history.

Sometimes it's nice to 'pretend' (a simplified history) that there is only the one latest series of this 'long lived feature branch' (along with a similar desire for 'gfw/next` and `gfw/seen`). (one method has been to `git replace` that merge commit `{/"Start the"}` with it's parent on a temporary basis).

From my reading of the `rev-list` manual this is similar to the <paths> TREESAME capability, but without specifying any paths (maybe just `.` ?).

* Is there an existing method for specifying that simplified history?
* Is there a proper term for the treesame condition of the commit-tree
(as recorded in the commit object)?
* Thought's on adding an option for `--follow-treesame`?

The desire also came up in my pondering about progressive/partial merges (how to represent/hold current state/history) of a large tree, whereby different authors take different 'bites at the melon' of merging a long lasting feature branch (the 'ball of mud' type), whereby the result could be an octopus merge of the main/feature/partial commits, which is repeated until the partial becomes a finalised merge (the book-ending and octo-merge is still wip, but would also benefit from the 'feature' merge technique used by GfW.

-- Philip