Diff And Patch Tricks
This page just has some miscellaneous tips and tricks for using diff and patch:
Table Of Contents:
- patchutils - A set of tools for manipulating patch files
- diffinfo - Tim Bird's tool for managing diff files.
- Diffinfo can filter and split diffs using file patterns and regular expression matches.
- Available here: Media:diffinfo
- qdiff - quick diff.
- This is a front-end for diff which ignores files with the same size and modification time. This speeds up diffs of large source tree (like the Linux kernel)
- Available here: Media:qdiff
- wdiff - word diff
- This is a program to show difference per-word, instead of per-line
- Available at: http://directory.fsf.org/GNU/wdiff.html
- Meld - Visual diff and merge tool with very nice graphic interface
- Available at: http://meld.sourceforge.net/
- Tkdiff - Graphical front end to the diff program
- Available at: http://sourceforge.net/projects/tkdiff/
Handling reject (.rej) files
using read-only .orig directories
Tim Bird's tips:
In order to save space and ensure consistency, I always keep some read-only original kernel trees around, and symlink to them whenever I need to to diffs.
In a "base" directory, I untar each full kernel tree, rename the top directory
with a ".orig" extension, and make the entire thing read-only with
chmod -R a-w *
In directory where I'm working, I symlink to this tree with a command like
ln -s ../base/linux-188.8.131.52.orig .
I always do diffs between these one of these read-only .orig directories and my working directory.
Geert Uytterhoeven wrote:
If you want to test a lot of trees, each with only a few changes, you may want to save disk space and manipulation time using these `tricks':
- Don't keep 'full' trees around, use 'cp -rl' to clone a tree using hard links and apply the patches to the cloned tree. In 2.6 (contrary to 2.4), it's safe to build in a hardlinked source tree.
Afterwards 'diff -purN' between the original and the cloned-and-modified tree is blazing fast (on Linux, at least :-). But be careful when editing files in such a cloned tree, to avoid unintentional modification of all copies of a file
Q. Do you know if there are any editor wrappers that check for this situation and do the right thing?
- Sorry, I don't know. Probably there are. Perhaps just enabling backups with vim
is sufficient. I just became used to manually deleting the file before saving the modified version. Also keeping pristine source trees owned by a different user (e.g. 'src') does help, by preventing you from making mistakes.
Someone was working on a dynamic library (to be preloaded using $LD_PRELOAD) that would wrap around open() and implement copy-on-write semantics for files in a (configurable) list of directories. You should be able to find it in the lkml archives. I never tried that library, though.
If you want to go the way of zillions of trees hardlinked together, you may want to take a look at 'same' (ftp://ftp.bitwizard.nl/same/), a utility to hard link together identical files.
Perhaps all of these tricks became useless with a decent revision control system like BitKeeper. But last time I used BitKeeper for the kernel, my (previous) machine had only 128 MiB of RAM and thus couldn't keep the whole tree in RAM, causing BitKeeper to be terrrible slow...
keep build files separate from source files
Geert Uytterhoeven wrote:
- To keep your source trees clean and uncluttered for easier diffing, build in a separate directory and use the `O=' feature of the 2.6 build system.