Difference between revisions of "Diff And Patch Tricks"

From eLinux.org
Jump to: navigation, search
(using hardlink tree copies: remove links to BitKeeper)
m (Mark "using hardlink tree copies" obsolete)
Line 41: Line 41:
=== using hardlink tree copies ===
=== using hardlink tree copies ===
'''[obsoleted by git and hardware advancement (RAM++)]'''
Geert Uytterhoeven wrote:
Geert Uytterhoeven wrote:

Latest revision as of 02:38, 4 June 2021

This page just has some miscellaneous tips and tricks for using diff and patch:

Table Of Contents:

diff-related tools

    • 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
    • Meld - Visual diff and merge tool with very nice graphic interface
    • Tkdiff - Graphical front end to the diff program


Handling reject (.rej) files

See Handling Patch Rejects

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 the following: ln -s ../base/linux- .

I always do diffs between these one of these read-only .orig directories and my working directory.

using hardlink tree copies

[obsoleted by git and hardware advancement (RAM++)]

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?

  1. 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.