From c3eccf5021eb15fa146e4faa4e4c7e5e150d3fc7 Mon Sep 17 00:00:00 2001 From: Mike Swanson Date: Tue, 31 Dec 2013 00:16:20 -0800 Subject: [PATCH] README: Reflect the project's actual methods When I wrote the README before, I was basically demanding the use of Git's signed-off messages, which is just wrong-headed. Also change the example commit so it uses an action stamp, no more hard dependency on a sha1 identifier that may change if the repository is rewritten (has happened) or moved to another VCS (has happened, also); additionally, it's just a better example commit to use. :-) Remove the "Build system" section which encouraged a "Do Not Touch" philosophy which is also wrong-headed. Any change for improvement is self-evident: should not tell people to not bother without explaining themselves. Also, rename the file so GitHub renders it nicely. --- README => README.asc | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-) rename README => README.asc (88%) diff --git a/README b/README.asc similarity index 88% rename from README rename to README.asc index 3c2b8655..28922ecb 100644 --- a/README +++ b/README.asc @@ -109,12 +109,6 @@ It is sensible to also heed the following guidelines: means no imps, cyberdemons, etc). The new monsters will behave the same way as the originals, but will be totally new. -=== Build process - -The Freedoom build process is fairly complete and should not change -without good reason. Write a decent explanation why your method is -better; just enough to get your point across is good enough. - === Documentation Freedoom always needs help with the documentation, so please send your @@ -138,18 +132,14 @@ patches, but keep in mind: TODO: Figure out the best method of doing this. This mainly requires time to see what works best. -If you use git, make sure your commit messages start with a single line, -under 72 characters, which provides an adequate summary of your changes. -You should prefix this line with the component you are committing (for -example, ``map17: fixed unbeatable map''). This should be followed by a -blank line and a paragraph or more to explain your change in detail (for -example, explaining what part of the map was broken). See commit -49dc6ca861d4b85ca16b219941ecb86d3e172ac1 for an example. Sign your -comments with +git commit -s+, these leaves a trail of whose hands a -commit went through and could be useful for some purposes; git alone can -give an indication of up to two people, however the AUTHOR/COMMITTER -fields are not quite reliable or flexible enough for the same -information. +If you use git, make sure your commit messages start with a single +line, under 72 characters, which provides an adequate summary of your +changes. You should prefix this line with the component you are commit +(for example, ``map17: fixed unbeatable map''). This should be +followed by a blank line and more explanation if it's needed (for +example, explaining what part of the map was broken). The commit +2013-12-20T16:06:55Z!rjy@users.sourceforge.net shows a good example of +a well-structured commit message. You should commit often; each important change should get its own commit, but minor changes need not. Take advantage of git's ability to