If you ever find yourself needing to maintain a set of patches to apply to two or more similar codebases (e.g. various linux kernels of various distros), I found stacked git to be very helpful for that purpose. http://www.procode.org/stgit/ (or maybe just apt-get install stgit).
Yes, I can definitely recommend stgit if what you're doing is basically "maintain this stack of patches". It's much more user-friendly as an UI for doing that than raw git rebase, though of course you can achieve the same workflow with the basic git plumbing.
Of course, this idea goes back further than "back in the 1980s" with Larry Wall.
In the mainframe world of the decade before that, people had ZAP, which later was to become SPZAP, OBJZAP, and AMASPZAP (not IAMASPZAP as the Hacker's Dictionary erroneously has it). ZAP's "NAME", "VER", and "REP" records work similarly to the process described by M. Landley: name the file, verify that the original contents at a particular place are thus, replace them with some new contents if so.
ZAP could also twiddle metadata, record patches applied, and dump contents. It has several imitators.
After reading the man page for diff and the -e option, I found that they actually generate the diff hunks from the end of the file to the beginning in order to keep the start line numbers consistent. I wonder why the other diff formats decided to do it the other way around (from beginning to end)? Doing it from end to beginning actually makes it easier to apply individual hunks without having to regenerate the diff after applying one (assuming you start with a later hunk before applying earlier ones).
