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

From: Denton Liu <liu.denton@gmail.com>
Date: Oct 2, 2019, 20:08 UTC
Message-ID: <20191002200836.GA24697@generichostname>
In-Reply-To: <xmqqd0ffdj9k.fsf@gitster-ct.c.googlers.com>

On Thu, Oct 03, 2019 at 04:44:55AM +0900, Junio C Hamano wrote:

Show 7 quoted lines

> 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.

Show 5 quoted lines

>  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.

> 
>