On Mon, Aug 01, 2022 at 03:38:59PM +0200, Omar Polo wrote:
> there's an edge case in locate_hunk with empty files; if `first_guess'
> is zero then main() assumes that locate_hunk has failed and aborts the
> patch operation. Instead, make sure to return 1 (the line number) so
> that the patch operation can continue.
>
> this issue was found by Neels Hofmeyr (I presume) in the diff
> implementation for got. The regress suite for diff.git expects that
> `patch && patch -R' is an identity and so currently fails with base
> patch(1).
>
> (while here i've also added a comment about t19 that was missing.)
>
> ok?
ok stsp@
Unrelated to the problem you are fixing, but worth mentioning anyway:
Both 'got patch' and Larry's patch(1) fail to create t20.in during
the application of your diff. This can be trivially worked around
by running "touch t20.in".
I am unsure how a new empty file should be represented in unidiff.
I would expect to see at least a hunk header of the form @@ -0,0 +0,0 @@
but none of 'cvs diff', 'svn diff', and 'git diff' produce any hunk
headers for added empty files. They just produce their own custom
meta-data lines. ('hg diff' is even worse and doesn't print anything).
Which probably means patch(1) would need to be tought about lines such
as "Index" or similar, which are usually treated as noise? Horrible.
Testing the above hunk header idea, this unidiff successfully tricks
Larry patch(1) into creating an empty file:
--- /dev/null
+++ regress/usr.bin/patch/t20.in
@@ -0,0 +0,0 @@
So I suppose this issue should be fixed in diff tooling rather than
trying to work around it in patch(1).
