From: Junio C Hamano Date: Thu, 18 Sep 2025 15:18:06 GMT Subject: Re: [PATCH v3] last-modified: fix bug when some paths remain unhandled Message-ID: In-Reply-To: <20250918-toon-fix-last-modified-v3-1-0c3910e224f6@iotcl.com> Toon Claes 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.