Turn 'em into git commits.
I've done this with a lot of things which only have changelogs and tarballs, it is convenient.
I've done this with a lot of things which only have changelogs and tarballs, it is convenient.
Seriously, that would be a beautiful thing from a historic standpoint. But there is no git client for 2.11BSD, so you'd also end up having to build a git->something (probably shell archive and b64 compressed tar) that could allow the 2.11BSD system to update itself (and we're talking a 16/22 bit system here). There are also changes that require kernel recompiles and/or reboots so it turns out to be an extremely difficult problem. Which is why there are these human readable patches.
I might be misunderstanding, but I don't think this is true. As long as there's a complete snapshot to start from anywhere in the revision history, it's possible to apply each patch in reverse (as far back as possible), even if it doesn't get all the way to patch level 0. Then later, if earlier patches are found, these can be applied in reverse and the branch rebased.
The way I see it, git's main role here would simply be a way to standardize patch format, not its usual role as a distributed software development aid.
For example: https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch...
I recently updated from patch level 462 to 469 (the most recently patch available) and even with excellent documentation, it was an involved process. If you look all the way back to the first set of patches (https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch...) there isn't even documentation for the most part. Some diffs, some random tar files, and some "Remove everything above the #! /bin/sh line." patches.
You might also want to mention it on the PiDP-11 Google Group (https://groups.google.com/forum/#!forum/pidp-11) where there are some original patchers and lots of other interested people.