Delete trailing whitespace in md files

doc/HACKING/CodingStandards.md

@@ -81,7 +81,7 @@ in changes to make a draft changelog, and clear the directory. We'll
 then edit the draft changelog into a nice readable format.
 
 What needs a changes file?
-   
+
    * A not-exhaustive list: Anything that might change user-visible
    behavior. Anything that changes internals, documentation, or the build
    system enough that somebody could notice.  Big or interesting code
@@ -89,7 +89,7 @@ What needs a changes file?
    did that happen, and/or why did we do that" 6 months down the line.
 
 Why use changes files instead of Git commit messages?
-   
+
    * Git commit messages are written for developers, not users, and they
    are nigh-impossible to revise after the fact.
 
@@ -151,7 +151,7 @@ Functions not to write
 ----------------------
 
 Try to never hand-write new code to parse or generate binary
-formats. Instead, use trunnel if at all possible.  See  
+formats. Instead, use trunnel if at all possible.  See
 
     https://gitweb.torproject.org/trunnel.git/tree
 

doc/HACKING/GettingStarted.md

@@ -40,8 +40,8 @@ Once you've reached this point, here's what you need to know.
   1. Get the source.
 
      We keep our source under version control in Git.  To get the latest
-     version, run  
-         
+     version, run
+
          git clone https://git.torproject.org/git/tor
 
      This will give you a checkout of the master branch.  If you're
@@ -54,7 +54,7 @@ Once you've reached this point, here's what you need to know.
 
      Our overall code structure is explained in the "torguts" documents,
      currently at
-     
+
         git clone https://git.torproject.org/user/nickm/torguts.git
 
      Find a part of the code that looks interesting to you, and start
@@ -88,7 +88,7 @@ Once you've reached this point, here's what you need to know.
      For your first patch, it is probably NOT a good idea to make
      something huge or invasive.  In particular, you should probably
      avoid:
-     
+
        * Major changes spread across many parts of the codebase.
        * Major changes to programming practice or coding style.
        * Huge new features or protocol changes.
@@ -182,9 +182,6 @@ Once you've reached this point, here's what you need to know.
          say so!  And if you won't have time to make some of the
          changes, you should say that too, so that other developers
          will be able to pick up the unfinished portion.
-         
+
     Congratulations!  You have now written your first patch, and gotten
     it integrated into mainline Tor.
-
-
-

doc/HACKING/HelpfulTools.md

@@ -101,7 +101,7 @@ working connection to the internet:
 
 Running gcov for unit test coverage
 -----------------------------------
- 
+
     ./configure --enable-coverage
     make
     make check
@@ -243,7 +243,7 @@ We use the 'doxygen' utility to generate documentation from our
 source code. Here's how to use it:
 
   1. Begin every file that should be documented with
-  
+
          /**
           * \file filename.c
           * \brief Short description of the file.
@@ -291,4 +291,3 @@ source code. Here's how to use it:
 
   6. See the Doxygen manual for more information; this summary just
      scratches the surface.
-

doc/HACKING/ReleasingTor.md

@@ -6,20 +6,20 @@ Here are the steps Roger takes when putting out a new Tor release:
 
 1. Use it for a while, as a client, as a relay, as a hidden service,
    and as a directory authority. See if it has any obvious bugs, and
-   resolve those.   
-   
+   resolve those.
+
    As applicable, merge the `maint-X` branch into the `release-X` branch.
 
 2. Gather the `changes/*` files into a changelog entry, rewriting many
    of them and reordering to focus on what users and funders would find
    interesting and understandable.
 
-   1. Make sure that everything that wants a bug number has one.   
+   1. Make sure that everything that wants a bug number has one.
       Make sure that everything which is a bugfix says what version
       it was a bugfix on.
-   
+
    2. Concatenate them.
-    
+
    3. Sort them by section. Within each section, sort by "version it's
       a bugfix on", else by numerical ticket order.
 
@@ -55,7 +55,7 @@ Here are the steps Roger takes when putting out a new Tor release:
       If a given changes stanza showed up in a different release (e.g.
       maint-0.2.1), be sure to make the stanzas identical (so people can
       distinguish if these are the same change).
-     
+
    5. Merge them in.
 
    6. Clean everything one last time.
@@ -94,7 +94,7 @@ Here are the steps Roger takes when putting out a new Tor release:
    in their approved versions list.
 
 7. Sign the tarball, then sign and push the git tag:
-   
+
         gpg -ba <the_tarball>
         git tag -u <keyid> tor-0.2.x.y-status
         git push origin tag tor-0.2.x.y-status
@@ -103,12 +103,12 @@ Here are the steps Roger takes when putting out a new Tor release:
    `/srv/dist-master.torproject.org/htdocs/` on dist-master. When you want
    it to go live, you run "static-update-component dist.torproject.org"
    on dist-master.
-    
+
    Edit `include/versions.wmi` and `Makefile` to note the new version.
 
 9. Email the packagers (cc'ing tor-assistants) that a new tarball is up.
    The current list of packagers is:
-   
+
        - {weasel,gk,mikeperry} at torproject dot org
        - {blueness} at gentoo dot org
        - {paul} at invizbox dot io