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

On Mon, 21 Sept 2026 at 09:49, Nikita Makarov <n.makarov@yadro.com> wrote:

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

Am 21.09.26 um 09:45 schrieb Nikita Makarov:

(No, it happens all the time, not just at the end of the file.)

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

On 9/21/26 09:45, Nikita Makarov wrote:

 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>