Re: [PATCH RFC 1/5] blame-tree: introduce new subcommand to blame files

[Junio C Hamano <gitster@pobox.com>]

Toon Claes <toon@iotcl.com> writes:

> Similar to git-blame(1), introduce a new subcommand git-blame-tree(1).
> This command shows the most recent modification to paths in a tree. It
> does so by expanding the tree at a given commit, taking note of the
> current state of each path, and then walking backwards through history
> looking for commits where each path changed into its final commit ID.

What is missing in the series is an end-user facing documentation,
it seems?  Don't take this as a complaint; an RFC is expected to be
incomplete and one of the reasons asking for comment responses is
to fill the gaps.

How is the "most recent modification" defined in a history with
forks and merges?  For example, in this topology:

 A---B---B---B---B---B
          \     /
           C---D

where each letter denotes the contents in the path we are interested
in (and as usual, time flows from left to right), is it the child of
commit A that made the last modification from A to B?  Or was it the
merge commit that compared B and D and decided that the path should
have B?  Something else?  Does it change the story if the sides of
the merge were swapped, i.e. if the branch that kept B all the way
were not the mainline but the side branch that got merged?

 A---B---B---C---D---B---B
          \         /
           B-------B

The same question applies if the path we are interested in is a
tree, not a leaf file.

I do not seem to see such a case that involves "ours" merge in the
tests, either.