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@xxxxxxxxx/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
