Re: [PATCH v3] last-modified: fix bug when some paths remain unhandled

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 18, 2025, 15:18 UTC
Message-ID: <xmqqy0qb94cx.fsf@gitster.g>
In-Reply-To: <20250918-toon-fix-last-modified-v3-1-0c3910e224f6@iotcl.com>

Toon Claes <toon@iotcl.com> writes:

Show 6 quoted lines

> The recently introduced new subcommand git-last-modified(1) runs into an
> error in some scenarios. It then would exit with the message:
>
>     BUG: paths remaining beyond boundary in last-modified
>
> This seems to happens for example when criss-cross merges are involved.

"seems to happens for example when" -> "seems to happen, for example, when".

"In some scenarios" followed by "seems to" is not particularly convincing that we know what the cause of the problem, though.

> In that scenario, the function diff_tree_combined() gets called.

and in a simpler history that does not exhibit the problem, we traverse without calling diff_tree_combined()? What do we use instead?

Show 8 quoted lines

> The function diff_tree_combined() copies the `struct diff_options` from
> the input `struct rev_info` to override some flags. One flag is
> `recursive`, which is always set to 1. This has been the case since the
> inception of this function in af3feefa1d (diff-tree -c: show a merge
> commit a bit more sensibly., 2006-01-24).
>
> This behavior is incompatible with git-last-modified(1), when called
> non-recursive (which is the default).

"non-recursively"?

Show 5 quoted lines

> Changes in v3:
> - Instead of changing diff_tree_combined()'s default behavior, add a
>   flag to modify it's behavior.
> - Overhaul the commit message to match the change in strategy.
> - Link to v2: https://lore.kernel.org/r/20250905-toon-fix-last-modified-v2-1-d859eeed408e@iotcl.com

I agree that this surgical approach may be the safest without risking regression to all other callers.

Will queue on top of recent 'master' that already has the tc/last-modified topic.

Thanks.