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

Toon Claes [off-list ref] 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 [off-list ref] writes:

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/ (local)
[2]: https://github.blog/open-source/git/highlights-from-git-2-55/
[3]: https://git-scm.com/docs/git-format-rev

-- 
Cheers,
Toon