Bugreport: git log -L

Bugreport: git log -L

[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. 

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 <t@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]

Re: Bugreport: git log -L

[Kristofer Karlsson]

On Mon, 21 Sept 2026 at 09:49, Nikita Makarov <n.makarov@yadro.com> 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 <t@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

Re: Bugreport: git log -L

[Johannes Sixt]

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

Re: Bugreport: git log -L

[Tim Tassonis]

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 <t@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 :<funcname> is given in place of <start> and <end>, it is a
regular expression that denotes the range from the first funcname
line that matches <funcname>, up to the next funcname line.
:<funcname> searches from the end of the previous -L range, if any,
otherwise from the start of file.  ^:<funcname> 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