Support patches without a prefix by determining the prefix depth

[Leonidas-from-XIV]

This reads the prefix depth from the file. We currently only support only 1 but this adds support for 0 which the regex already supported.

For arbitrary depth prefixes this would require a more complex parsing regex but also these are presumably rather rare in the real world.

[rgrinberg]

Is a prefix always a relative path?

[Leonidas-from-XIV]

That's a good question and I never thought about it so tried what the tools do. diff -u will gladly generate a patch with an absolute path:

--- /tmp/diffy/old	2024-09-06 09:48:02.146670822 +0200
+++ /tmp/diffy/new	2024-09-06 09:48:10.369718133 +0200
@@ -1 +1 @@
-This is wrong.
+This is right.

However if I have the files at the locations and use patch -p0 it will refuse to apply the patch:

$ patch -p0 < absolute.patch
Ignoring potentially dangerous file name /tmp/diffy/old
Ignoring potentially dangerous file name /tmp/diffy/new
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?

If I instead call it from /tmp/diffy and strip the 2 components it will still not do it correctly:

$ patch -p2 < absolute.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?

However, if I turn the absolute path /tmp/diffy/... into a relative tmp/diffy/... it applies the patch correctly with -p2 so I assume that patch can only handle relative paths.

In our case the only prefixes that the regex can ever match are "", "a/" and "b/" but the calculation function is a little bit more robust.

[rgrinberg]

Okay, then I think we can assume only a relative path is valid then. what about a trailing slash on the relative path, is that accepted? Also if trailing slashes are allowed, how is just / interpreted?

Reason why I'm asking is that I'm not sure using string operations on slashes is the robust approach here. I would much prefer to see things converted to Path.Local.t and operated on using path functions.

[Leonidas-from-XIV]

Reason why I'm asking is that I'm not sure using string operations on slashes is the robust approach here. I would much prefer to see things converted to Path.Local.t and operated on using path functions.

Yes you're right, that is nicer. I've converted it to use Path.Local functions, there are some pretty useful ones to deal with this exact case. I've moved the handling of the prefix from the regex to the OCaml code, that way the prefix handling is in one place.