Subject: Re: Antw: [EXT] Re: git add --interactive patch improvement for split hunks

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Mon, 28 Jun 2021 13:20:46 +0200

On Mon, Jun 28 2021, Ulrich Windl wrote:

>>>> Jeff King <[email-masked]> schrieb am 24.06.2021 um 17:41 in Nachricht
> <[email-masked]>:
>
> [...]
>> 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/[email-masked]/

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.