From: Gusted <gusted@codeberg.org>
To: Toon Claes <toon@iotcl.com>,
git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: git-last-modified(1) slower than git-log(1)?
Date: Fri, 17 Jul 2026 02:19:49 +0200 [thread overview]
Message-ID: <6491c7e6-9310-4a5e-8ba5-9d3a2e7e3312@codeberg.org> (raw)
In-Reply-To: <87v7afffpa.fsf@emacs.iotcl.com>
On 7/16/26 11:26 AM, Toon Claes wrote:
> Hi Gusted,
>
> Thanks for reaching out.
>
> You're actually not the first to notice this, and I've been aware of
> this.
>
> The thing is, you're testing the difference on a single file. For us at
> GitLab, it wasn't very useful to optimize that use-case, because usually
> we want to see the last commit for a bunch of files at once.
> So the use-case for git-last-modified(1) for us has been to replace
> (pseudo code):
>
> $ FILES=$(git ls-tree $COMMIT $PATH)
> $ foreach $FILE in $FILES; do git log -1 $COMMIT -- $FILE; end
>
> GitLab is batching files 25 at once, and in my benchmarking, it was
> shown git-last-modified(1) is faster:
>
> $ git last-modified $COMMIT -- <files
>
> (I did this benchmarking in our Gitaly component to have a real-world
> experience and you can visit the results at:
> https://gitlab.com/gitlab-org/gitaly/-/merge_requests/7999#note_2850505479
> )
>
> So we left the door open for future improvement, although I never have
> gotten to it. At some point I was trying to chase down when git-log(1)
> was doing differently, but I never figured it out.
>
> But this email challenged me already. And with some help of AI, I
> managed to work on some improvements. You can expect a patch series
> soon.
>
> (Right before sending out this mail I noticed Peff sent out some changes
> as well. I'll coordinate how to combine.)
>
Hi Toon and Jeff,
Thanks for having a look at this!
The use case for Forgejo is the same as Gitlab then, we only use it to
get the last-modified of each entry in a directory. Looking a bit closer
I missed that in Forgejo's code it's considered the output might not
have the answer of all entries, and happily calls it as many time is
needed on the 'remaining paths', especially when using gitlab as
repository this required a lot of git-log calls.
Looking at the mentioned benchmark, yeah this is where Forgejo's
implementation with git-log would fail in terms of performance
(seemingly even slower than doing N-1 git-log calls, by using your
benchmark numbers). It's somewhere in the minutes :')
Kind Regards
Gusted
next prev parent reply other threads:[~2026-07-17 0:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 18:33 git-last-modified(1) slower than git-log(1)? Gusted
2026-07-16 4:28 ` Jeff King
2026-07-16 11:42 ` Toon Claes
2026-07-17 8:09 ` Jeff King
2026-07-16 9:26 ` Toon Claes
2026-07-17 0:19 ` Gusted [this message]
2026-07-17 8:02 ` Jeff King
2026-07-17 19:12 ` Toon Claes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6491c7e6-9310-4a5e-8ba5-9d3a2e7e3312@codeberg.org \
--to=gusted@codeberg.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=toon@iotcl.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.