Git development
 help / color / mirror / Atom feed
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

      reply	other threads:[~2026-07-17  0:19 UTC|newest]

Thread overview: 5+ 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-16  9:26 ` Toon Claes
2026-07-17  0:19   ` Gusted [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox