Re: Bugreport: git log -L

From: Johannes Sixt <j6t@kdbg.org>
Date: Sep 21, 2026, 16:40 UTC
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