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

From: Toon Claes <toon@iotcl.com>
Date: May 7, 2025, 13:13 UTC
Message-ID: <87h61wimxj.fsf@iotcl.com>
In-Reply-To: <xmqqfrhxv8fn.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

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

Yes, I'm aware that was missing, but I didn't want to spend too much time on this if the general idea would be discarded anyway.

Show 24 quoted lines

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

Those are good scenarios to think about. I'll try to include them in test cases for the next version. I think it's easier to argue about it then.

-- Toon