Toon Claes <toon@xxxxxxxxx> 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.
