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