Re: [BUG] incorrect line numbers reported in git am

[Denton Liu <liu.denton@gmail.com>]

On Thu, Oct 03, 2019 at 04:44:55AM +0900, Junio C Hamano wrote:
> Denton Liu <liu.denton@gmail.com> writes:
> 
> > 	Applying: dir: special case check for the possibility that pathspec is NULL
> > 	error: corrupt patch at line 87
> 
> This refers to line 87 of the input file, not a line that begins
> with "@@ -87,count...", doesn't it?

Correct, it refers to line 87 of the input file. Since the whole mail is
202 lines long and the faulty hunk comes at the end of the whole mail,
I'd expect the faulty line number to say something like line 198 or
something that's near the end of the mail. Line 87 is somewhere in the
middle of the log message in the mail.

I think the problem comes from line number being expressed as an offset
from the "---" (begin diff) line as opposed to an offset from the actual
beginning of the mail.

>  If the sender hand edits a
> patch without correcting the number of lines recorded in the hunk
> header, the parser may not see the next hunk that begins with "@@"
> or run out of the input before it reads the required number of lines
> given the last hunk header.

Correct, but I think that's orthogonal to the main issue. It makes sense
why the error is being reported but what doesn't make sense is the fact
that the line numbers reported are so far off from what a user would
expect.

> 
> We might be able to notice when the input file is shorter than the
> last hunk wants it to be, in which case we should be able to say
> 'premature end of input at line 87' or something like that.

Yep, I noticed this bug while I was writing a patch to do exactly that.

> 
>