PATCH(1)PATCH(1)NAMEpatch - simple patch creation and tracking system
patch/create name email files ... [ < description ]
patch/list [ name ... ]
patch/note name [ < note ]
These scripts are a simple patch submission and tracking system used to
propose additions or changes to Plan 9. There is no guarantee that any
patch will be accepted, nor that it will be accepted verbatim. Each
patch has a name (lowercase letters, numbers, dash, dot, and underscore
only) and is stored in /n/sources/patch/name.
Patch/create creates a new patch consisting of the changes to the
listed text files from the distribution, reading a description of the
patch from standard input: please provide an explanation of what the
change is supposed to do, some context, and a rationale for the change.
Please do not submit binary files. Test data or pointers to same to
verify that the fix works are also welcome. When sending a patch, fol‐
low these guidelines:
· Before preparing the patch, run replica/pull and base your patch on
current distribution source code.
· If this is a bug fix, explain the bug clearly. Don't assume the bug
is obvious from the fix.
· If this is a new feature, explain it clearly. Don't assume it is
obvious from the change.
· Make the new code look as much like the old code as possible: don't
make gratuitous changes, and do follow the style of the old code.
See style(6) for the canonical Plan 9 coding style.
· If your patch changes externally-visible behaviour, update the man‐
The email address, if not will be sent notification messages when the
patch is applied, rejected, or commented on. If rejected, the e-mail
will contain a note explaining why and probably listing suggested
changes and encouraging you to resubmit.
Patch/list displays information about the named patches, or all cur‐
rently pending patches if none are specified.
Patch/diff shows a patch as diffs between the original source files and
the patched source files.
Patch/apply applies the patch to the current source tree. It is
intended to be run by the Plan 9 developers with pie as their root file
system. If the source has changed since the patch was created, apply
will report the conflict and not change any files. Before changing any
files, patch/apply makes backup copies of the current source tree's
files. The backups are stored in the patch directory.
Patch/undo will copy the backups saved by patch/apply back into the
source tree. It will not restore a backup if the file being replaced
is not byte-identical to the one created by patch/apply.
Propose a change to pwd, which you have modified locally:
% patch/create pwd-errors firstname.lastname@example.org /sys/src/cmd/pwd.c
Fix pwd to print errors to fd 2 rather than 1.
Then the developers at Bell Labs run
to inspect the change (possibly viewing /n/sources/patch/pwd-
errors/pwd.c to see the larger context). To make the change, they run
Otherwise they run
% patch/note pwd-errors
Pwd should definitely print errors to fd 1 because ...
to add a note to the /n/sources/pwd-errors/notes file.