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

From: Toon Claes <toon@iotcl.com>
Date: Jul 17, 2026, 19:12 UTC
Message-ID: <87fr1h1ldr.fsf@emacs.iotcl.com>
In-Reply-To: <87v7afffpa.fsf@emacs.iotcl.com>

Toon Claes <toon@iotcl.com> writes:

> You're actually not the first to notice this, and I've been aware of
> this.

Hah, wait, ... the previous reporter was ... you[1].

> The thing is, you're testing the difference on a single file.

I was mixing up use-cases, and the problem you're stating here isn't related to your previous report. Now while I did sent out patches for the problem in this email, the issue in the other email isn't addressed with it. Unfortunately.

(nerdsniping Peff :-))

Gusted <gusted@codeberg.org> writes:

Show 5 quoted lines

> The current implementation of Forgejo (inherited from Gitea) works
> roughly like this:
> 1. Run `git log --name-status -c --format=commit%x00%H %P%x00" --parents
> --no-renames -t -z $OID -- :(literal)some/path`, the output of this is
> quite complex and possible outputs more information than necessary.

That's quite clever actually.

> 2. The output of this is piped to some code to a parser and reconstructs
> what commit ID last modified each file in the directory.

My only worry would be this could end up in a very long list of (duplicate) commits. But you can probably filter out data as you read in lines.

> 3. Via `git cat-file --batch` get each unique commits information.

Yes we use git-cat-file(1) in batch mode too.

But, and I learned this from blog post[2] from GitHub about Git v2.55, git v2.55 now has git-format-rev(1)[3]. You can pipe the output of git-last-modified(1) into that and get everything you want at once (maybe).

I haven't tried yet to integrate that into GitLab to see if it would bring any gains.

[1]: https://lore.kernel.org/git/03f96860-29fc-42a7-a220-c3ec65eb8516@codeberg.org/ [2]: https://github.blog/open-source/git/highlights-from-git-2-55/ [3]: https://git-scm.com/docs/git-format-rev

-- 
Cheers,
Toon