patch

As freshly documented at http://drupal.org/patch/apply

git apply will fail to do anything when used within a local checkout of a git repository (other than the one for the project the patch is made for), such as if you are patching a module that is within a site that is in Git version control. Use patch -p1 < path/file.patch instead.

wget -O - http://example.org/testfix.patch | patch -p0

From http://groups.drupal.org/node/91424

where deviantintegral suggested
curl http://drupal.org/files/1234_fix.patch | patch -p0

catch telling chrisshattuck in IRC: I keep one checkout + db, reset the checkout with cvs -q diff | patch -p0 -R and usually re-use the database until it's completely dead.

--no-prefix

Do not show any source or destination prefix.

Reference

http://www.kernel.org/pub/software/scm/git/docs/git-diff.html

Take the hash of a 'before' commit and the 'after' commit 'sha' hash and stay relative to the current directory and output a patch:

~/code/dgd7/drupal/sites/all/modules/views$ git diff --relative 5ac40a1 cb64d08 > 817748-views-book-hierarchy-sort-12.patch

If you've merely made the changes but not committed them you can use git diff > patch_name-1234-57.patch or if you've staged but not committed you can use git diff --cached patch_name-1234-57.patch.

There are various approaches to getting a usable development environment working on a Microsoft Windows machine. Here are some:

VirtualBox

Best bet, virtualbox? Let's you make believe you're actually on, say Debian Linux.

http://www.virtualbox.org/wiki/Downloads

$ cvs update -C

(Locally modified node.admin.inc moved to .#node.admin.inc.1.24)
(Locally modified node.module moved to .#node.module.1.974)
(Locally modified taxonomy.admin.inc moved to .#taxonomy.admin.inc.1.27)
(Locally modified taxonomy.module moved to .#taxonomy.module.1.425)
(Locally modified taxonomy.test moved to .#taxonomy.test.1.3)

[... and a ton more stuff]

cvs update -C will move all the files you have changed to a renamed file and bring down the originals again.

Resolution

webchick talking to Michelle in IRC #drupal:

I name all my patches as {module_name}-{description-of-changes}-{issue_node_id}-{issue_comment_id}.patch

Personally, I think issue_comment_id might be hard to do (even interpreted as the big #5 etc project module places in the comment title, rather than the internal Drupal ID!) since people can add comments while you are making the patch, but I'm on board with the ideal.

Getting into that habit also really forces you to keep to a one-issue-one-change thing.