Antw: [EXT] Re: git add --interactive patch improvement for split hunks
- From
- Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
- Date
- Jun 28, 2021, 10:10 UTC
- Message-ID
- <60D9A01C020000A100042099@gwsmtp.uni-regensburg.de>
- In-Reply-To
- <YNSnlhbE30xDfVMY@coredump.intra.peff.net>
>>> Jeff King <peff@peff.net> schrieb am 24.06.2021 um 17:41 in Nachricht
<YNSnlhbE30xDfVMY@coredump.intra.peff.net>:
[...]
Show 32 quoted lines
> 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.
Show 8 quoted lines
> > -Peff > > [0] I'm not sure what the timetable is for switching to the C version of > add--interactive. If it's going to be a while, I don't mind moving > forward the other patch I showed. But maybe the time is here to > think about switching the default of add.interactive.useBuiltin, and > ironing out any final bugs?