PATCH(1) PATCH(1)
NAME
patch - simple patch creation and tracking system
SYNOPSIS
patch/create name email files ... [ < description ]
patch/list [ name ... ]
patch/diff name
patch/apply name
patch/undo name
patch/note name [ < note ]
DESCRIPTION
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 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. Test data or
pointers to same to verify that the fix works are also wel-
come. When sending a patch, follow 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 pos-
sible: 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 manual page.
The email address, if not `-', will be sent notification
Page 1 Plan 9 (printed 12/21/24)
PATCH(1) PATCH(1)
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 currently 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.
EXAMPLES
Propose a change to pwd, which you have modified locally:
% patch/create pwd-errors user@host.dom /sys/src/cmd/pwd.c
Fix pwd to print errors to fd 2 rather than 1.
^D
%
Then the developers at Bell Labs run
patch/diff pwd-errors
to inspect the change (possibly viewing
/n/sources/patch/pwd-errors/pwd.c to see the larger con-
text). To make the change, they run
patch/apply pwd-errors
Otherwise they run
% patch/note pwd-errors
Pwd should definitely print errors to fd 1 because ...
^D
%
to add a note to the /n/sources/pwd-errors/notes file.
FILES
Page 2 Plan 9 (printed 12/21/24)
PATCH(1) PATCH(1)
/n/sources/patch
SOURCE
/rc/bin/patch
SEE ALSO
diff(1)
http://plan9.bell-labs.com/wiki/plan9/How_to_contribute
Page 3 Plan 9 (printed 12/21/24)