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

[Philip Oakley <philipoakley@iee.email>]

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