Re: What's cooking in git.git (Nov 2025, #03; Fri, 7)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 12, 2025, 16:13 UTC
- Message-ID
- <xmqqecq3tej2.fsf@gitster.g>
- In-Reply-To
- <87jyzvwgs0.fsf@iotcl.com>
Toon Claes <toon@iotcl.com> writes:
Show 14 quoted lines
> 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.
I plan to exclude, especially if it was not merged to 'next' before 2025-10-30, which is one calendar week before -rc1, to give the topic the usual cooking period.
> Maybe it wasn't very clear how I phrased it in the v4 cover letter[1], > but without this patch, some results are wrong:
Indeed it was unclear. With respect to the output, the only thing I recalled was (I just went back to the thread)
One thing to note though, the results might be outputted in a different
order than before. This is not considerd to be an issue because nowhere
is documented the order is guaranteed.and the patch came with a single test that gives a much later than before in check_last_modified output, which does not clearly demonstrate how the old results were wrong and the new results correct them.
Show 21 quoted lines
>> 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/