# Bugreport: git log -L 4 messages from 2026-09-21 to 2026-09-21. Participants: Nikita Makarov, Kristofer Karlsson, Johannes Sixt, Tim Tassonis. Thread: https://gitlist.dev/t/66358 ## Nikita Makarov, 2026-09-21 07:45 Subject: Bugreport: git log -L Message-ID: <41c54b809eb1490fb467ba0fd4c5a8cf@yadro.com> ``` Hello, I have the found the strange behavior of "git log -L" command with python function. It is counting a blank line that sits after a function's last statement as part of that function. This happens only when the function is at the end of a file.  The way to reproduce that git init repro && cd repro git config user.email t@t && git config user.name t printf 'def foo():\n    return 1\n\n' > bug.py git add bug.py && git commit -qm c1 printf 'def foo():\n    return 1\n' > bug.py git add bug.py && git commit -qm c2 Then do git log -L :'foo':bug.py And you'll see Author: t Date:   Fri Sep 18 18:21:10 2026 +0300     c2 diff --git a/bug.py b/bug.py --- a/bug.py +++ b/bug.py @@ -1,2 +1,3 @@  def foo():      return 1 + Though I expect that commit "c2" should never appear in log, since the changes from it doesn't affect the functions body at all.  [System Info] git version: git version 2.43.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 7.0.0-31-generic #31~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Aug 10 09:38:02 UTC 2 x86_64 compiler info: gnuc: 13.3 libc info: glibc: 2.39 $SHELL (typically, interactive shell): /bin/bash [Enabled Hooks] ``` ## Kristofer Karlsson, 2026-09-21 09:49 Subject: Re: Bugreport: git log -L Message-ID: In-Reply-To: <41c54b809eb1490fb467ba0fd4c5a8cf@yadro.com> ``` On Mon, 21 Sept 2026 at 09:49, Nikita Makarov wrote: > > Hello, I have the found the strange behavior of "git log -L" command with python function. > It is counting a blank line that sits after a function's last statement as part of that function. > This happens only when the function is at the end of a file. > > The way to reproduce that > > git init repro && cd repro > git config user.email t@t && git config user.name t > > printf 'def foo():\n return 1\n\n' > bug.py > git add bug.py && git commit -qm c1 > > printf 'def foo():\n return 1\n' > bug.py > git add bug.py && git commit -qm c2 > > Then do > > git log -L :'foo':bug.py > > And you'll see > > Author: t > Date: Fri Sep 18 18:21:10 2026 +0300 > > c2 > > diff --git a/bug.py b/bug.py > --- a/bug.py > +++ b/bug.py > @@ -1,2 +1,3 @@ > def foo(): > return 1 > + > > Though I expect that commit "c2" should never appear in log, since the changes from it doesn't affect the functions body at all. I tried to reproduce this but failed to do so. I first started wondering if this meant the bug had been fixed in master already, but then I also failed to reproduce it on 2.43. I think the reproduction steps were wrong here, perhaps you meant to put the double newline in c2 instead of in c1? Because if I change that, I can reproduce it. So the steps should have: printf 'def foo():\n return 1\n' > bug.py git add bug.py && git commit -qm c1 printf 'def foo():\n return 1\n\n' > bug.py git add bug.py && git commit -qm c2 instead. I think I should be able to submit a fix for this shortly. Thanks, Kristofer ``` ## Johannes Sixt, 2026-09-21 16:40 Subject: Re: Bugreport: git log -L Message-ID: <4c88bb3c-4005-41bc-8ff5-9b8597aa05eb@kdbg.org> In-Reply-To: <41c54b809eb1490fb467ba0fd4c5a8cf@yadro.com> ``` Am 21.09.26 um 09:45 schrieb Nikita Makarov: > Hello, I have the found the strange behavior of "git log -L" command > with python function. It is counting a blank line that sits after a > function's last statement as part of that function. This happens > only when the function is at the end of a file. (No, it happens all the time, not just at the end of the file.) > Though I expect that commit "c2" should never appear in log, since > the changes from it doesn't affect the functions body at all. Most likely, Git has successfully kept up the illusion that it knows what "a function" is in your programming language, because you have frequently seen function names in hunk headers. But the truth is, Git doesn't know. For the purpose of `git log -L :function_name:file`, Git uses the same pattern as for the hunk headers to determine function boundaries. In particular, a function ends right before the next function begins (if there is one). By this metric, any blank lines (and comments!) before the next function count to the previous function. So, what you are seeing here is to be expected for the lack of a better notion of what "a function" is. If we are to improve on this, then a more serious problem to fix is that comments above a function do not count to the function that they document, but to the previous function. -- Hannes ``` ## Tim Tassonis, 2026-09-21 18:04 Subject: Re: Bugreport: git log -L Message-ID: In-Reply-To: <41c54b809eb1490fb467ba0fd4c5a8cf@yadro.com> ``` On 9/21/26 09:45, Nikita Makarov wrote: > Hello, I have the found the strange behavior of "git log -L" command with python function. > It is counting a blank line that sits after a function's last statement as part of that function. > This happens only when the function is at the end of a file. > > The way to reproduce that > > git init repro && cd repro > git config user.email t@t && git config user.name t > > printf 'def foo():\n    return 1\n\n' > bug.py > git add bug.py && git commit -qm c1 > > printf 'def foo():\n    return 1\n' > bug.py > git add bug.py && git commit -qm c2 > > Then do > > git log -L :'foo':bug.py > > And you'll see > > Author: t > Date:   Fri Sep 18 18:21:10 2026 +0300 > >     c2 > > diff --git a/bug.py b/bug.py > --- a/bug.py > +++ b/bug.py > @@ -1,2 +1,3 @@ >  def foo(): >      return 1 > + > > Though I expect that commit "c2" should never appear in log, since the changes from it doesn't affect the functions body at all. From git log --help ... If : is given in place of and , it is a regular expression that denotes the range from the first funcname line that matches , up to the next funcname line. : searches from the end of the previous -L range, if any, otherwise from the start of file. ^: searches from the start of file. The function names are determined in the same way as git diff works out patch hunk headers (see Defining a custom hunk-header in gitattributes(5)). .. So, the bug is rather the expectation that such a thing can reliably know what a function is, regardless of coding style and language used. To quote the late and great Christopher Tolkien: This could only be achieved. if at all, at heavy and needless cost. Bye> > [System Info] > git version: > git version 2.43.0 > cpu: x86_64 > no commit associated with this build > sizeof-long: 8 > sizeof-size_t: 8 > shell-path: /bin/sh > uname: Linux 7.0.0-31-generic #31~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Aug 10 09:38:02 UTC 2 x86_64 > compiler info: gnuc: 13.3 > libc info: glibc: 2.39 > $SHELL (typically, interactive shell): /bin/bash > > > [Enabled Hooks] -- decentral.ch - IT Stuff Tim Tassonis Badenerstrasse 219 8003 Zürich stuff@decentral.ch +41 79 229 36 17 ```