{"thread":{"id":"64717","subject":"git-last-modified weirdness","startedAt":"2026-01-04T05:13:30Z","lastAt":"2026-01-05T11:54:23Z","messageCount":3,"participants":["Gusted","Toon Claes"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"532974","messageId":"03f96860-29fc-42a7-a220-c3ec65eb8516@codeberg.org","threadId":"64717","inReplyTo":"406222e6-d10b-47d8-a177-de5912db4512@codeberg.org","subject":"git-last-modified weirdness","fromName":"Gusted","fromEmail":"gusted@codeberg.org","sentAt":"2026-01-04T05:13:27Z","receivedAt":"2026-01-04T05:13:30Z","isPatch":false,"sender":{"key":"gusted@codeberg.org","avatar":null},"body":"Hi,\n\nResending this mail as it looks like it might not have arrived (couldn't \nfind\nit in the mailing list archive).\n\nFor Forgejo, I wanted to look into using git-last-modified to gain extra\nperformance for larger repositories where this can often result in being \n(one\nof) the slowest git operation. However I noticed some problems that \nlooks to\nbe bugs.\n\nI've ran all the following commands on the following Git repository, on Git\nv2.52.0 (Arch Linux) and my git config does not enable or disable any \nfeature\nthat should've impacted the any of the following observations.\n\n$ tmp=$(mktemp -d)\n$ git clone https://codeberg.org/forgejo/forgejo $tmp\n$ cd tmp\n\nDuring some experiments I noticed it being slower for some files. An \nexample:\n\n$ hyperfine --warmup 5 'git log --max-count=1 DCO' 'git last-modified DCO'\nBenchmark 1: git log --max-count=1 DCO\n   Time (mean ± σ):      86.9 ms ±   0.8 ms    [User: 70.1 ms, System: \n15.6 ms]\n   Range (min … max):    85.5 ms …  88.3 ms    34 runs\n\nBenchmark 2: git last-modified DCO\n   Time (mean ± σ):     151.3 ms ±   4.3 ms    [User: 133.4 ms, System: \n15.9 ms]\n   Range (min … max):   145.4 ms … 167.1 ms    19 runs\n\n\n\nThis might be me misunderstanding the feature, but it looks to me this \ncannot\nbe used for paths that is inside a directory. The following two commands \nyield\nthe same output:\n\n$ git last-modified -- web_src\n24019ef5e83fd7bed7f31ad09dd8d5f26b4bdc69        web_src\n$ git last-modified -- web_src/svg\n24019ef5e83fd7bed7f31ad09dd8d5f26b4bdc69        web_src\n\nWhere I expected the latter command to return the last commit of \nweb_src/svg.\n\n\n\nI'm not sure why I tried this, but I can trigger a BUG when giving it some\nnonsense input:\n\n$ git last-modified fb06ce04173d47aaaa498385621cba8b8dfd7584\nBUG: builtin/last-modified.c:456: paths remaining beyond boundary in\nlast-modified\n[1]    690163 IOT instruction (core dumped)  git last-modified\n\n`fb06ce04173d47aaaa498385621cba8b8dfd7584` is the tree commit id of \nweb_src. I\nsuppose this should've returned a nice error message or blank output. It \ndoes\ngive a blank output when you specify a valid path:\n\n$ git last-modified fb06ce04173d47aaaa498385621cba8b8dfd7584 web_src\n\nKind regards,\nGusted\n\n"},{"id":"533025","messageId":"87v7hgpbrk.fsf@iotcl.com","threadId":"64717","inReplyTo":"03f96860-29fc-42a7-a220-c3ec65eb8516@codeberg.org","subject":"Re: git-last-modified weirdness","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2026-01-05T10:57:51Z","receivedAt":"2026-01-05T10:58:07Z","isPatch":false,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Gusted <gusted@codeberg.org> writes:\n\n> Hi,\n>\n> Resending this mail as it looks like it might not have arrived (couldn't \n> find it in the mailing list archive).\n\nThanks for following up. I didn't see it yet.\n\n> For Forgejo, I wanted to look into using git-last-modified to gain extra\n> performance for larger repositories where this can often result in being \n> (one of) the slowest git operation. However I noticed some problems that \n> looks to be bugs.\n>\n> I've ran all the following commands on the following Git repository, on Git\n> v2.52.0 (Arch Linux) and my git config does not enable or disable any \n> feature that should've impacted the any of the following observations.\n>\n> $ tmp=$(mktemp -d)\n> $ git clone https://codeberg.org/forgejo/forgejo $tmp\n> $ cd tmp\n>\n> During some experiments I noticed it being slower for some files. An \n> example:\n>\n> $ hyperfine --warmup 5 'git log --max-count=1 DCO' 'git last-modified DCO'\n> Benchmark 1: git log --max-count=1 DCO\n>    Time (mean ± σ):      86.9 ms ±   0.8 ms    [User: 70.1 ms, System: 15.6 ms]\n>    Range (min … max):    85.5 ms …  88.3 ms    34 runs\n>\n> Benchmark 2: git last-modified DCO\n>    Time (mean ± σ):     151.3 ms ±   4.3 ms    [User: 133.4 ms, System: 15.9 ms]\n>    Range (min … max):   145.4 ms … 167.1 ms    19 runs\n\nIn my local benchmarks I see similar results.\n\nI agree this isn't great, but git-log(1) is just very good at logging a\nsingle path. git-last-modified(1) is mostly designed to give commits\nfor a bunch of paths. For example:\n\n    $ hyperfine --warmup 5 'git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 --format=oneline --' 'git last-modified'\n    Benchmark 1: git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 --format=oneline --\n      Time (mean ± σ):     852.5 ms ±   9.2 ms    [User: 703.8 ms, System: 141.9 ms]\n      Range (min … max):   841.9 ms … 869.4 ms    10 runs\n\n    Benchmark 2: git last-modified\n      Time (mean ± σ):     141.2 ms ±   2.0 ms    [User: 133.0 ms, System: 7.9 ms]\n      Range (min … max):   137.7 ms … 146.0 ms    21 runs\n\n    Summary\n      git last-modified ran\n        6.04 ± 0.11 times faster than git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 --format=oneline --\n\n> This might be me misunderstanding the feature, but it looks to me this \n> cannot be used for paths that is inside a directory. The following two commands \n> yield the same output:\n>\n> $ git last-modified -- web_src\n> 24019ef5e83fd7bed7f31ad09dd8d5f26b4bdc69        web_src\n> $ git last-modified -- web_src/svg\n> 24019ef5e83fd7bed7f31ad09dd8d5f26b4bdc69        web_src\n>\n> Where I expected the latter command to return the last commit of \n> web_src/svg.\n\nI agree this is confusing. And I plan to propose a change to this\nbehavior. But at the moment what you're supposed to do in this\nsituation:\n\n    $ git last-modified -- web_src\n    28e0af23faf6c8e8f353ba2ae818ee0f83fd3e5c        web_src\n    $ git last-modified -r --max-depth=0 -- web_src/svg\n    b8f15e4ea09c6571872607874ae099269ea4b201        web_src/svg\n\nI plan to change the default behavior to basically behave like `-r\n--max-depth=0`. But I'm happy to hear your input if you think it should\nbe something else?\nThere's some context here[1], but as said, I might shift direction a bit\ntoward making the default more intuitive.\n\n[1]: https://lore.kernel.org/git/20251126-toon-last-modified-zzzz-v1-0-608350df0caa@iotcl.com/\n\n> I'm not sure why I tried this, but I can trigger a BUG when giving it some\n> nonsense input:\n>\n> $ git last-modified fb06ce04173d47aaaa498385621cba8b8dfd7584\n> BUG: builtin/last-modified.c:456: paths remaining beyond boundary in\n> last-modified\n> [1]    690163 IOT instruction (core dumped)  git last-modified\n>\n> `fb06ce04173d47aaaa498385621cba8b8dfd7584` is the tree commit id of \n> web_src. I\n> suppose this should've returned a nice error message or blank output. It \n> does\n> give a blank output when you specify a valid path:\n>\n> $ git last-modified fb06ce04173d47aaaa498385621cba8b8dfd7584 web_src\n>\n\nHah, that sounds like a real bug. Thanks for reporting, I will look into\nit.\n\n> Kind regards,\n> Gusted\n>\n>\n\n-- \nCheers,\nToon\n"},{"id":"533030","messageId":"4b6fe686-bb3d-4d10-8a4d-7542b4c93e45@codeberg.org","threadId":"64717","inReplyTo":"87v7hgpbrk.fsf@iotcl.com","subject":"Re: git-last-modified weirdness","fromName":"Gusted","fromEmail":"gusted@codeberg.org","sentAt":"2026-01-05T11:52:01Z","receivedAt":"2026-01-05T11:54:23Z","isPatch":false,"sender":{"key":"gusted@codeberg.org","avatar":null},"body":"On 1/5/26 11:57 AM, Toon Claes wrote:\n\n > Gusted <gusted@codeberg.org> writes:\n >\n >> Hi,\n >>\n >> Resending this mail as it looks like it might not have arrived (couldn't\n >> find it in the mailing list archive).\n > Thanks for following up. I didn't see it yet.\n >\n >> For Forgejo, I wanted to look into using git-last-modified to gain extra\n >> performance for larger repositories where this can often result in being\n >> (one of) the slowest git operation. However I noticed some problems that\n >> looks to be bugs.\n >>\n >> I've ran all the following commands on the following Git repository, \non Git\n >> v2.52.0 (Arch Linux) and my git config does not enable or disable any\n >> feature that should've impacted the any of the following observations.\n >>\n >> $ tmp=$(mktemp -d)\n >> $ git clone https://codeberg.org/forgejo/forgejo $tmp\n >> $ cd tmp\n >>\n >> During some experiments I noticed it being slower for some files. An\n >> example:\n >>\n >> $ hyperfine --warmup 5 'git log --max-count=1 DCO' 'git \nlast-modified DCO'\n >> Benchmark 1: git log --max-count=1 DCO\n >>     Time (mean ± σ):      86.9 ms ±   0.8 ms    [User: 70.1 ms, \nSystem: 15.6 ms]\n >>     Range (min … max):    85.5 ms …  88.3 ms    34 runs\n >>\n >> Benchmark 2: git last-modified DCO\n >>     Time (mean ± σ):     151.3 ms ±   4.3 ms    [User: 133.4 ms, \nSystem: 15.9 ms]\n >>     Range (min … max):   145.4 ms … 167.1 ms    19 runs\n > In my local benchmarks I see similar results.\n >\n > I agree this isn't great, but git-log(1) is just very good at logging a\n > single path. git-last-modified(1) is mostly designed to give commits\n > for a bunch of paths. For example:\n >\n >      $ hyperfine --warmup 5 'git ls-tree HEAD --name-only | xargs \n--max-args=1 git log --max-count=1 --format=oneline --' 'git last-modified'\n >      Benchmark 1: git ls-tree HEAD --name-only | xargs --max-args=1 \ngit log --max-count=1 --format=oneline --\n >        Time (mean ± σ):     852.5 ms ±   9.2 ms    [User: 703.8 ms, \nSystem: 141.9 ms]\n >        Range (min … max):   841.9 ms … 869.4 ms    10 runs\n >\n >      Benchmark 2: git last-modified\n >        Time (mean ± σ):     141.2 ms ±   2.0 ms    [User: 133.0 ms, \nSystem: 7.9 ms]\n >        Range (min … max):   137.7 ms … 146.0 ms    21 runs\n >\n >      Summary\n >        git last-modified ran\n >          6.04 ± 0.11 times faster than git ls-tree HEAD --name-only | \nxargs --max-args=1 git log --max-count=1 --format=oneline --\nOnly using git-last-modified when there are more than a few paths is\nokay for how I want to use it. I was not really able to deduce this\nfrom the manual, the general feeling after reading Github blog, Gitlab\nblog and the release notes of v2.52.0 it looked to be a good\nreplacement of git log -n1 in all cases.\n >> This might be me misunderstanding the feature, but it looks to me this\n >> cannot be used for paths that is inside a directory. The following \ntwo commands\n >> yield the same output:\n >>\n >> $ git last-modified -- web_src\n >> 24019ef5e83fd7bed7f31ad09dd8d5f26b4bdc69        web_src\n >> $ git last-modified -- web_src/svg\n >> 24019ef5e83fd7bed7f31ad09dd8d5f26b4bdc69        web_src\n >>\n >> Where I expected the latter command to return the last commit of\n >> web_src/svg.\n > I agree this is confusing. And I plan to propose a change to this\n > behavior. But at the moment what you're supposed to do in this\n > situation:\n >\n >      $ git last-modified -- web_src\n >      28e0af23faf6c8e8f353ba2ae818ee0f83fd3e5c        web_src\n >      $ git last-modified -r --max-depth=0 -- web_src/svg\n >      b8f15e4ea09c6571872607874ae099269ea4b201        web_src/svg\n >\n > I plan to change the default behavior to basically behave like `-r\n > --max-depth=0`. But I'm happy to hear your input if you think it should\n > be something else?\n > There's some context here[1], but as said, I might shift direction a bit\n > toward making the default more intuitive.\n >\n > [1]: \nhttps://lore.kernel.org/git/20251126-toon-last-modified-zzzz-v1-0-608350df0caa@iotcl.com/\n\nOh, there's a whole new option! That's exactly what I was looking for\nto get that behavior. Only returning the root level information by\ndefault looks and feels silly and does remind me of git-diff-tree's\ndefault, so I would agree on having -r --max-depth=0 as the default.\nReturning the information exactly for the paths being given sounds most\nreasonable.\n\nAlthough given you mention that this command works best for multiple\npaths I can also imagine -r --max-depth=1 as default to nudge people to\nuse it for that purpose.\n\n >> I'm not sure why I tried this, but I can trigger a BUG when giving \nit some\n >> nonsense input:\n >>\n >> $ git last-modified fb06ce04173d47aaaa498385621cba8b8dfd7584\n >> BUG: builtin/last-modified.c:456: paths remaining beyond boundary in\n >> last-modified\n >> [1]    690163 IOT instruction (core dumped)  git last-modified\n >>\n >> `fb06ce04173d47aaaa498385621cba8b8dfd7584` is the tree commit id of\n >> web_src. I\n >> suppose this should've returned a nice error message or blank output. It\n >> does\n >> give a blank output when you specify a valid path:\n >>\n >> $ git last-modified fb06ce04173d47aaaa498385621cba8b8dfd7584 web_src\n >>\n > Hah, that sounds like a real bug. Thanks for reporting, I will look into\n > it.\n >\n >> Kind regards,\n >> Gusted\n >>\n >>\n\nKind Regards\nGusted\n"}]}