• Choose a category
• All
• Classic-Fiction

The diffstat command generates a histogram of the modifications made to each file in a patch. It provides a good way to “get a sense of” a patch—which files it affects, and how much change it introduces to each file and as a whole. (I find that it’s a good idea to use diffstat’s -p option as a matter of course, as otherwise it will try to do clever things with prefixes of filenames that inevitably confuse at least me.)

$ diffstat -p1 remove-redundant-null-checks.patch

drivers/char/agp/sgi-agp.c | 5 ++---

drivers/char/hvcs.c | 11 +++++------

drivers/message/fusion/mptfc.c | 6 ++----

drivers/message/fusion/mptsas.c | 3 +--

drivers/net/fs_enet/fs_enet-mii.c | 3 +--

drivers/net/wireless/ipw2200.c | 22 ++++++----------------

drivers/scsi/libata-scsi.c | 4 +---

drivers/video/au1100fb.c | 3 +--

8 files changed, 19 insertions(+), 38 deletions(-)

$ filterdiff -i '*/video/*' remove-redundant-null-checks.patch

--- a/drivers/video/au1100fb.c~remove-redundant-null-checks-before-free-in-drivers

+++ a/drivers/video/au1100fb.c

@@ -743,8 +743,7 @@ void __exit au1100fb_cleanup(void)

{

driver_unregister(&au1100fb_driver);

- if (drv_info.opt_mode)

- kfree(drv_info.opt_mode);

+ kfree(drv_info.opt_mode);

}

module_init(au1100fb_init);

The patchutils package is invaluable. It provides a set of small utilities that follow the “Unix philosophy”: each does one useful thing with a patch. The patchutils command I use most is filterdiff, which extracts subsets from a patch file. For example, given a patch that modifies hundreds of files across dozens of directories, a single invocation of filterdiff can generate a smaller patch that only touches files whose names match a particular glob pattern. See Viewing the History of a Patch for another example.

Good Ways to Work with Patches

Whether you are working on a patch series to submit to a free software or open source project, or a series that you intend to treat as a sequence of regular changesets when you’re done, you can use some simple techniques to keep your work well organized.

Give your patches descriptive names. A good name for a patch might be rework-device-alloc.patch, because it will immediately give you a hint of the purpose of the patch. Long names shouldn’t be a problem; you won’t be typing the names often, but you will be running commands like qapplied and qtop over and over. Good naming becomes especially important when you have a number of patches to work with, or if you are juggling a number of different tasks and your patches only get a fraction of your attention.

Be aware of what patch you’re working on. Use the qtop command and skim over the text of your patches frequently—for example, using hg tip -p—to be sure of where you stand. I have several times worked on and qrefreshed a patch other than the one I intended, and it’s often tricky to migrate changes into the right patch after making them in the wrong one.

For this reason, it is very much worth investing a little time to learn how to use some of the third-party tools I described in Third-Party Tools for Working with Patches, particularly diffstat and filterdiff. The former will give you a quick idea of what changes your patch is making, while the latter makes it easy to splice hunks selectively out of one patch and into another.

MQ Cookbook

Managing “Trivial” Patches

Because the overhead of dropping files into a new Mercurial repository is so low, it makes a lot of sense to manage patches this way even if you simply want to make a few changes to a source tarball that you downloaded.

Begin by downloading and unpacking the source tarball, and turning it into a Mercurial repository.

$ download netplug-1.2.5.tar.bz2

$ tar jxf netplug-1.2.5.tar.bz2

$ cd netplug-1.2.5

$ hg init

$ hg commit -q --addremove --message netplug-1.2.5

$ cd ..

$ hg clone netplug-1.2.5 netplug

updating working directory

18 files updated, 0 files merged, 0 files removed, 0 files unresolved

Continue by creating a patch