Re: git-last-modified(1) slower than git-log(1)?

From: Jeff King <peff@peff.net>
Date: Jul 17, 2026, 08:02 UTC
Message-ID: <20260717080216.GB1832790@coredump.intra.peff.net>
In-Reply-To: <87v7afffpa.fsf@emacs.iotcl.com>

On Thu, Jul 16, 2026 at 11:26:25AM +0200, Toon Claes wrote:

Show 5 quoted lines

> 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):

That was my assumption at first, too, but I think the log command there really is returning results for the whole subtree. You just have to post-process it to pick out the files from each commit.

> $ FILES=$(git ls-tree $COMMIT $PATH)
> $ foreach $FILE in $FILES; do git log -1 $COMMIT -- $FILE; end

Yeah, that is the most horrible way to do it. It's expensive in processes, but also in walking over the same set of history repeatedly.

The log in Gusted's example does a single walk, but it is up to the caller to then interpret the walk results. That would add extra time, but I think it scales independently of the time difference he's observing. In his hyperfine results, last-modified is scaling with the total numbers of commits in the repo, but processing the output scales to the number of commits which actually touched the subtree in question.

So I think it really could perform better than last-modified, even with the post-processing step (which we didn't see nor time). But we should be able to do better in last-modified using similar top-level commit filtering.

-Peff