User login


git apply does not work from within the local checkout of an unrelated git repository

As freshly documented at

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.

Repeated testing of core patches with CVS

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.

Getting a git diff with a relative path (no a/ b/ prefixes)


Do not show any source or destination prefix.


Creating a patch with Git suitable for submitting to

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.

Testing patches for Drupal from a Windows machine

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


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

Reset your Drupal checkout so that it is clean and ready to try more patches

$ cvs update -C
(Locally modified moved to
(Locally modified node.module moved to .#node.module.1.974)
(Locally modified moved to
(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.


Patch naming conventions for Drupal core and contrib

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.

Syndicate content