[9front] patch(1) filename detection

[9front] patch(1) filename detection

[Michael Forney]

I recently encountered an issue using patch and git.

Say I remove two files in git and generate a patch:

diff 0890cdaa2d2a6ad756ba98130e078b3cd64bee7d 5b6279eb53ece69d2a014adf566f22adb61d94e4
--- a/a
+++ /dev/null
@@ -1,1 +1,0 @@
-foo
--- a/b
+++ /dev/null
@@ -1,1 +1,0 @@
-bar

When I try to apply this, we process the first hunk. curfile is nil,
so we set it to /dev/null, then read the contents of a into f, and
apply the hunk.  Then, we get to the second hunk. It also has newpath
of /dev/null, so we *do not* read the contents of b. However, now we
are searching for the contents of b in a, which fails:

	stdin:8: unable to find hunk offset in b

Historically, I believe patch implementations worked by using the
first file that existed of the --- name and the +++ name, falling back
to prompting the user for the name of the file to patch. The new
9front patch works a bit differently and patches the --- name into the
+++ name, with a bit of logic to remove files with /dev/null as the
+++ name.

I don't think this is ideal behavior, because it is common to see
patches like

--- a.orig	Wed Sep 28 21:53:55 2022
+++ a		Wed Sep 28 21:53:58 2022
@@ -1 +1 @@
-foo
+bar

for example in BSD ports systems. Given this file, patch(1) will
complain

	patch: open a.orig: 'a.orig' file not found

rather than patching the file a. Similarly, given a patch like

--- a
+++ a.new
@@ -1,1 +1,1 @@
-foo
+bar

patch(1) will write the patched file to a.new and leave a alone
rather than patching a.

I propose we implement the standard behavior in patch(1) (maybe
without the prompting part) to interoperate better with patches
created by other tools. This will fix the issue I encountered since
there is no separate "old path" and "new path", just the file selected
for patching.

We can still retain the logic to remove the file if the +++ name is
/dev/null. However, longer term it might be worth supporting the
git-diff extended header lines:

	deleted file mode <mode>
	new file mode <mode>
	old mode <mode>
	new mode <mode>

There are also headers for renames and copies, but I don't think git
or patch should bother with that, and should just present them as
deleted and added files.

Thoughts?

Re: [9front] patch(1) filename detection

[unobe]

Quoth Michael Forney <mforney@mforney.org>:
> However, longer term it might be worth supporting the
> git-diff extended header lines:
> 
> 	deleted file mode <mode>
> 	new file mode <mode>
> 	old mode <mode>
> 	new mode <mode>
> 
> There are also headers for renames and copies, but I don't think git
> or patch should bother with that, and should just present them as
> deleted and added files.
> 
> Thoughts?

There's also:
	similarity index <number>
	dissimilarity index <number>

Would one (or both) of those be useful if we're now talking about
modes, too?  Also, looking at the latest docs, I wasn't clear on what
the difference between 'deleted file mode', 'new file mode', 'old
mode', and 'new mode'.  For a patch, what's the purpose of all four of
them?  If a file is deleted, why isn't 'old mode' just used, and when
a file created, why isn't 'new mode' used?

The latest git docs also talk about combined diff mode, and it being
the default format with git-diff and git-show:

	index <hash>,<hash>..<hash>
	mode <mode>,<mode>..<mode>
	new file mode <mode>
	deleted file mode <mode>

That's not desired, right?

Reference: https://git-scm.com/docs/diff-format/2.37.2