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

Toon Claes [off-list ref] 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 (local)

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.