[BUG] incorrect line numbers reported in git am

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

Hello all,

I found a bug where the line numbers in git am are being reported
incorrectly in the case where a patch fails to apply cleanly.

The test case for this is pretty simple:

	$ wget https://public-inbox.org/git/20191001185524.18772-1-newren@gmail.com/raw
	$ git am raw

And the output for this is:

	Applying: dir: special case check for the possibility that pathspec is NULL
	error: corrupt patch at line 87
	Patch failed at 0001 dir: special case check for the possibility that pathspec is NULL
	hint: Use 'git am --show-current-patch' to see the failed patch
	When you have resolved this problem, run "git am --continue".
	If you prefer to skip this patch, run "git am --skip" instead.
	To restore the original branch and stop patching, run "git am --abort".

In this case, the path is indeed corrupt. The final hunk header gives 25
lines after instead of 24 lines. As a result, it is erroring out
correctly.

However, the line offsets are off. Line 87, as it reports, is the
following:

	to avoid a segfault.

which is in the middle of the log message. I expect the line to be
reported as something in the range of 198-203, where the end of the hunk
actually is.

Indeed, if you take an 87 line offset from the cutoff "---", we can see
that it gives us line 201, which appears at the end of the corrupt hunk.

So it appears that the bug is a result of the the apply process not
taking into account the number of lines from the mail parsing step.

Thanks,

Denton