archives/freedoom
2
0
Fork 0
mirror of https://github.com/freedoom/freedoom.git synced 2025-09-03 10:25:46 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

README: Reflect the project's actual methods

Browse source 
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.
This commit is contained in:
Mike Swanson 2013-12-31 00:16:20 -08:00
parent 71d7922528
commit c3eccf5021
1 changed files with 8 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

26
README → README.asc
View file

@ -109,12 +109,6 @@ It is sensible to also heed the following guidelines:
means no imps, cyberdemons, etc). The new monsters will behave the means no imps, cyberdemons, etc). The new monsters will behave the
same way as the originals, but will be totally new. 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 === Documentation
Freedoom always needs help with the documentation, so please send your 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 TODO: Figure out the best method of doing this. This mainly requires
time to see what works best. time to see what works best.
If you use git, make sure your commit messages start with a single line, If you use git, make sure your commit messages start with a single
under 72 characters, which provides an adequate summary of your changes. line, under 72 characters, which provides an adequate summary of your
You should prefix this line with the component you are committing (for changes. You should prefix this line with the component you are commit
example, ``map17: fixed unbeatable map''). This should be followed by a (for example, ``map17: fixed unbeatable map''). This should be
blank line and a paragraph or more to explain your change in detail (for followed by a blank line and more explanation if it's needed (for
example, explaining what part of the map was broken). See commit example, explaining what part of the map was broken). The commit
49dc6ca861d4b85ca16b219941ecb86d3e172ac1 for an example. Sign your 2013-12-20T16:06:55Z!rjy@users.sourceforge.net shows a good example of
comments with +git commit -s+, these leaves a trail of whose hands a a well-structured commit message.
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.
You should commit often; each important change should get its own You should commit often; each important change should get its own
commit, but minor changes need not. Take advantage of git's ability to commit, but minor changes need not. Take advantage of git's ability to