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

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

Toon Claes <toon@iotcl.com> writes:

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

> 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"?

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