Re: [PATCH] date: remove approxidate_relative()

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>> Instead, imagine --extra-context='<range>:<path>' were the way to
>> tell Git to include the specified range of lines in the post context
>> even though they may not have been modified.  Then René's patch
>> could have been produced with
>> 
>>     $ git format-patch -1 \
>>       --extra-context='/^timestamp_t approxidate_careful/,/^}$/:date.c'
>> 
>> and would have shown 3 lines of precontext before the removed
>> approxidate_relative(), plus the unchanged approxidate_careful()
>> function in full in the postcontext.
>
> Ooh, I like that very much. In that sense it really feels like an
> extension of --function-context. Would the regexes be searches starting
> from the edge of some context (as they more or less are under the hood
> for function context), or would you search within the whole file for
> ranges (and then presumably use them when a hunk's context is adjacent
> to or overlaps a range)?
>
> If the latter, I guess you could also allow both absolute and relative
> line numbers, similar to how "-L" accepts range input.

We want the latter.

If we further imagine that approxidate_careful() were defined very
far away (in either direction) from approxidate_relative() that
"extending" the patch context to show the removal of the latter to
cover the former would show too much irrelevant information, I think
René would have wanted to show a normal patch plus an extra hunk
that contains the entirety of approxidate_careful() that shows no
modification (i.e. all lines are prefixed with an SP).  The way I
think about this new "feature" is "compute what hunks should be
shown, honoring all other options.  Then pretend no-op hunks to
cover all specified lines in the postimage [*] are also in the
result.  Combine them all, ignoring parts of the made-up no-op hunks
when they contradict the real hunks.".  The end result should show
all specified lines from the postimage plus the usual diff.


[Footnote]

 * There is no need for a similar option to talk about lines in the
   preimage, because a line in the preimage would either appear in
   the postimage (in which case the range in the postimage can be
   used to show it), or otherwise it would appear as deleted line
   (in which case the reader will see it without the new feature.