The text is good, but the placement is not quite right. 3.4. Phases is a reference section, it should not contain tutorials, but it may link to one. 13.5. Patches and 14.1. Making patches are closer to the right place.

Section 14.1 doesn't seem relevant to this; I'll move it to 13.5.

I have not though about the best placement, I hope you'll chose right, but it seems appropriate for this to be a second level, not a third level section. Extending chapter 2 without creating a subsection also seems fine, because that chapter is a tutorial on adding packages, and this sometimes requires patching.

Updated. I moved it into chapter 13 because I think it fits well alongside the discussion of when to commit patch files versus using fetchpatch, and I updated the text slightly to tie those concepts together.

I don't believe that Patches section really belongs under the "coding conventions" chapter, but I think that's a different conversation.

Would it make sense to use filterdiff --strip=0 --clean like fetchpatch does?

The only effect of filterdiff on git diff output seems to be the stripping of the first two lines:

diff --git a/a b/a
index e69de29..6178079 100644

Personally I've never bothered to remove them, and I'd prefer to keep the instructions simple.

I'd be happy to change

git diff > nixpkgs/pkgs/the/package/0001-changes.patch

to

nix-shell --pure --packages git patchutils --run "git diff | filterdiff --strip=0 --clean > nixpkgs/pkgs/the/package/0001-changes.patch"

Not including extraneous information in the nixpkgs repo seems very desirable to me. The command is harder to understand, but in exchange you get a patch file that's easier to understand, so seems like a worthwhile tradeoff.

I think the instructions as-is are great, and the extra complexity of filterdiff isn't worth the benefits for this use case. Whereas, fetchpatch uses filterdiff to keep stable patch contents (shasum) when upstreams sometimes change bits of metadata (which are filtered.)