Add a ~p parameter to Patch.parse mimicking the behaviour of patch -p<num>

[kit-ty-kate]

PR on top of #20

This is required when dealing with both git and GNU diffs. The user of the library cannot know which name was there to begin with an cannot eliminate the prefix in the filenames accordingly.

Requiring a ~p parameter allows to give all the filenames cleanly and also to mimic the behaviour from GNU patch:

If the header is that of a context diff, patch takes the old and new file names in the header.
A name is ignored if it does not have enough slashes to satisfy the -pnum or --strip=num op‐
tion. The name /dev/null is also ignored.

[hannesm]

Thanks, this looks great. I force-pushed (rebased on main now that #7 is merged), and added a commit which fixes the tests.

The only question I have is about "rename_only", namely in test/git2.diff:

diff --git a/git2.old b/git2.new
similarity index 100%
rename from git2.old
rename to git2.new

And here our header / parser now returns git2.old / git2.new -- without the a and b. Is this a good solution? My worry is that, since now we support ~p and also remove the hard-coded "if diff is originating from git, drop the a/ / b/", we end up in an inconsistent state (in the rename_only case). Can we assume that rename from / rename to always originates from git, and add a a/ / b/ there? Or is there another path we should follow?

[hannesm]

I added another commit, please let me know if this works fine for you (esp. the rename case). I think this is good.

[hannesm]

thanks @kit-ty-kate, API-wise this looks fine to me, and is an appreciated cleanup.

[kit-ty-kate]

I fixed the behaviour with adjacent slashes (per GNU patch's behaviour) and added some tests. Merging