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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 24, 2025, 16:19 UTC
Message-ID: <xmqqfrhxv8fn.fsf@gitster.g>
In-Reply-To: <20250422-toon-new-blame-tree-v1-1-fdb51b8a394a@iotcl.com>

Toon Claes <toon@iotcl.com> writes:

Show 5 quoted lines

> 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.