Re: What's cooking in git.git (Nov 2025, #03; Fri, 7)

[Toon Claes <toon@iotcl.com>]

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

> * tc/last-modified-active-paths-optimization (2025-10-23) 1 commit
>   (merged to 'next' on 2025-11-03 at 9ab444edfb)
>  + last-modified: implement faster algorithm
>
>  "git last-modified" was optimized by narrowing the set of paths to
>  follow as it dug deeper in the history.
>
>  Will cook in 'next'.
>  source: <20251023-b4-toon-last-modified-faster-v3-1-40a4ddbbadec@iotcl.com>

Do you plan to include these changes in the upcoming v2.52 release? I
would like to argue to include them.

Maybe it wasn't very clear how I phrased it in the v4 cover letter[1],
but without this patch, some results are wrong:

> As an added benefit, results are more consistent now. For example
> implementation in 'master' gives:
> 
>     $ git log --max-count=1 --format=%H -- pkt-line.h
>     15df15fe07ef66b51302bb77e393f3c5502629de
> 
>     $ git last-modified -- pkt-line.h
>     15df15fe07ef66b51302bb77e393f3c5502629de	pkt-line.h
> 
>     $ git last-modified | grep pkt-line.h
>     5b49c1af03e600c286f63d9d9c9fb01403230b9f	pkt-line.h
> 
> With the changes in this patch the results of git-last-modified(1)
> always match those of `git log --max-count=1`.

So this patch speeds up git-last-modified(1), but it also fixes some
buggy results. That's why I consider this a bug fix and worthy to make
it into the upcoming release. (which is by the way also the first
release that includes this subcommand)

[1]: https://lore.kernel.org/git/20251103154726.26592-1-toon@iotcl.com/

-- 
Cheers,
Toon