Junio C Hamano <gitster@xxxxxxxxx> writes:
> Jeff King <peff@xxxxxxxx> writes:
>
>> On Sat, Dec 15, 2007 at 03:02:02PM -0500, Jeff King wrote:
>>
>>> > for (i = 0, recovered = 0; recovered < trimmed && i <= ctx; i++) {
>>> > while (recovered < trimmed && ap[recovered++] != '\n')
>>> > ; /* nothing */
>>> > }
>>> >
>>> > then (warning: I haven't had my coffee yet)?
>>>
>>> Yes, I think that is equivalent. My sleep-deprived brain keeps thinking
>>> there must be a more clear way of writing this whole loop, but it
>>> escapes me at the moment.
>>
>> And this came to me in a dream. :) It fixes the bug, and I think it is a
>> bit simpler to see the termination conditions in a single loop. But
>> please double-check correctness, and that you agree that it is more
>> readable.
>
> I wanted to recover to the end of the line that includes the cut-off
> point, even when (ctx == 0), to be extra safer, but I do not think it
> was necessary.
I have to wonder what happens if the last line which is incomplete has
more than block bytes that are identical at the end? We need to recover
the whole thing to show the correct diff, don't we?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
