On Mon, Jun 28 2021, Ulrich Windl wrote:
>>>> Jeff King <peff@xxxxxxxx> schrieb am 24.06.2021 um 17:41 in Nachricht
> <YNSnlhbE30xDfVMY@xxxxxxxxxxxxxxxxxxxxxxx>:
>
> [...]
>> One thing you may not like, though: both the builtin version and that
>> patch only put the funcname context in the _first_ hunk of the split.
>> Doing it for subsequent hunks is much trickier, since there can be a
>> funcname in the split context itself. E.g.:
>>
>> @@ ... @@ void foo()
>> int x;
>> - int y = 1;
>> + int y = 2;
>>
>> - x = 3;
>> + x = 4;
>> }
>>
>> could split into two hunks, both annotated with "void foo()". But:
>>
>> @@ ... @@ void foo()
>> int x;
>> - x = 3;
>> + x = 4;
>> }
>> void bar()
>> {
>> - int y = 1;
>> + int y = 2;
>> }
>>
>> would be wrong to say "void foo()" for the second hunk. We'd have to
>> re-scan the interior context lines for a funcname to find it. That's
>> all-but-impossible in the perl version, but might be do-able in the C
>> version (since it has easy access to the funcname-matching patterns and
>> machinery).
>
> There always was a related bug (IMHO) that showed the context of the
> previous function even though the actual change was within a new
> function (that starts within the context lines). So if that bug were
> fixed, my guess is that the other would be as well.
> However I don't know how easy or hard the fix will be.
> Maybe the "definition" of function context is just different; I don't really know.
Does that bug perhaps have anything to do with:
https://lore.kernel.org/git/20210215155020.2804-2-avarab@xxxxxxxxx/
I have some planned fixes to that behavior, but it's currently blocked
on a combination of myself having a lot of outstanding patches, and that
linked patch needing another series (as of yet unsubmitted/un-re-rolled)
to get us proper testing in this area of git. I.e. our testing of what
function context we should find is really lacking.
