indent(1) on the code after applying it.
I'll likely run my indent(1) on the code anyway though,
just to make sure the spacing is consistent, if nothing else.
+
Telodendria aims at remaining as minimal as possible. This doesn't
@@ -611,29 +614,52 @@ opening a "pull request," you should be pleased to hear that submitting
patches is fairly easy to do if you've got the CVS sources checked out.
In fact, I find it easier than having to make a GitHub account, forking
a project repository, and then making a pull request for it. Once you
-have made your changes in your local copy of the code, just run
-cvs diff:
+have made your changes in your local copy of the code, just run the
+patch recipe:
-At this point, it would be a good idea to open up your patch file in
-your preferred editor and look it over to make sure everything looks
-good. While you have the file open, you should also add some
-email-style headers to the top of your patch file, for quick
-identification:
+This will automatically generate the patch file from all your changes,
+and then open it in your default editor. You can set the
+EDITOR variable to your preferred editor if the default
+doesn't work for you. Either set it in your environment via your
+preferred means, or set it like this:
+
+You can also generate a patch for only certain files and directories.
+To do that, set PATCH, like this:
+
+You can of course specify both PATCH and
+EDITOR at the same time, if you want. But at that point,
+it might make more sense to just set them in .env or in
+your system environment.
+
+As you'll notice, the top of the patch file should have some email-style +headers that look like this:
-Obviously, set the actual values to your own information. From
-should be your name and Matrix ID, and Date should be in the format
-%Y-%m-%d. The Subject should very briefly
-describe what the patch is about. Below these headers, write a more in-depth
+As much information as possible should be filled out for you, such as the
+date. An attempt to fill out the From header was also made,
+but the information there can be made more accurate by setting
+MXID to your Matrix ID, and DISPLAY_NAME to your
+real name. The Subject should very briefly describe what
+the patch is about. Below these headers, write a more in-depth
description of the patch.
@@ -670,12 +696,18 @@ or email, it might be a good idea to link to it in the public patch directory.
The public patch directory works as follows: as soon as your patch is recieved,
-it will be downloaded and placed in the queue/ directory. Then,
-if your patch is accepted, it will be moved to the accepted/
-directory and then committed to the official CVS repository. If you patch is
-rejected for some reason, it will be moved to the rejected/
-directory. Regardless of the state of your patch, it will always be permalinked
-in the p/ directory.
+it is downloaded and placed in the ingress/ directory with the
+original name it was given. Eventually, it will be assigned an ID and moved
+to the p/ directory. There is a permanent link that will
+always reference your patch. Then, your patch is symlinked to the
+queue/ directory. I have a script that automatically ingresses
+patches and queues them for me, and I'll use this to review patches.
+If your patch is accepted, the queue symlink will be moved to the
+accepted/ directory and the patch is committed to the official
+CVS repository. If you patch is rejected for some reason, its symlink will
+be moved to the rejected/ directory. Regardless of the state
+of your patch, it will always remain permalinked in the p/
+directory.
You're always welcome to inquire about rejected patches, and request they be