Reformatting.

1 files changed, 21 insertions, 21 deletions

diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn
index ad488ebf..044cf6ce 100644
--- a/rules/source_repositories.mdwn
+++ b/rules/source_repositories.mdwn
@@ -17,17 +17,17 @@ for *hurd*).
 Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create
 branches without formal permission:
 
-  * named *BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]* for private general-purpose or
+  * named `BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]` for private general-purpose or
     topic branches, respectively, or
-  * named *BASE_BRANCH-TOPIC* for public topic branches basing on
-    *BASE_BRANCH*.
+  * named `BASE_BRANCH-TOPIC` for public topic branches basing on
+    `BASE_BRANCH`.
 
-*TOPIC* shall be a suitable tag describing the branch's main concern.  These
-tags can be applied recursively (*TOPIC-SUBTOPIC-SUBSUBTOPIC*).
+`TOPIC` shall be a suitable tag describing the branch's main concern.  These
+tags can be applied recursively (`TOPIC-SUBTOPIC-SUBSUBTOPIC`).
 
 *private* vs. *public* does, of course, in this scenario not mean visibility,
 but instead authority: *private* branches are those that the user
-*SAVANNAH_LOGIN* has authority over, whereas public branches are open for
+`SAVANNAH_LOGIN` has authority over, whereas public branches are open for
 every committer to install changes on.  The private branches are those that
 you would typically host on your own machine and publish through your own web
 server, but we offer that you can instead do this from the centralized Savannah
@@ -38,18 +38,18 @@ Examples:
 
   * GNU Mach
 
-      * *master* -- the mainline branch
-      * *master-oskit* -- port to OSKit; branched off of *master* at some point
-      * *master-gdb_stubs* -- add support for GDB stubs; branched off of
-        *master* at some point
+      * `master` -- the mainline branch
+      * `master-oskit` -- port to OSKit; branched off of `master` at some point
+      * `master-gdb_stubs` -- add support for GDB stubs; branched off of
+        `master` at some point
 
   * libpthread
 
-      * *master* -- the mainline branch
-      * *master-viengoos* -- port to Viengoos; branched off of *master* at some
+      * `master` -- the mainline branch
+      * `master-viengoos` -- port to Viengoos; branched off of `master` at some
         point
-      * *master-viengoos-on-bare-metal* -- port to Viengoos running on bare
-        metal; branched off of *master-viengoos* at some point
+      * `master-viengoos-on-bare-metal` -- port to Viengoos running on bare
+        metal; branched off of `master-viengoos` at some point
 
 ## Merging
 
@@ -61,7 +61,7 @@ different working topics, as this really faciliates concentrating on one
 specific working topic.
 
 You are encouraged to regularely merge from the respective mainline branches
-(*BASE_BRANCH*; should be *master* in most cases) into your working branches,
+(`BASE_BRANCH`; should be `master` in most cases) into your working branches,
 and ensure that your modifications are still fine in the context of new
 mainline changes.
 
@@ -82,31 +82,31 @@ Equivalent rules apply.
 Usually, branches are to be eventually merged back into their respective
 mainline branches.  To faciliate (and also to help other contributors) we'd
 like you to write a short summary log in a top-level (or wherever else
-appropriate) `ChangeLog.*TOPIC*` file.
+appropriate) `ChangeLog.TOPIC` file.
 
 Examples:
 
   * GNU Mach
 
-      * *master-gdb_stubs*: `ChangeLog.gdb`
+      * `master-gdb_stubs`: `ChangeLog.gdb`
 
-This need not be a full-fledged [GNU-style *ChangeLog*
+This need not be a full-fledged [GNU-style `ChangeLog`
 file](http://www.gnu.org/prep/standards/html_node/Change-Logs.html).  E.g.,
-don't waste time writing *ChangeLog* entries for debugging stuff that will be
+don't waste time writing `ChangeLog` entries for debugging stuff that will be
 removed again before merging back into mainline.  But please do write
 something.  Short notes.
 
 ### Behavior on *private* branches
 
 Even though you are said to be the owner of branches tagged with your
-*SAVANNAH_LOGIN*, it is generally nevertheless good to not do history-rewriting
+`SAVANNAH_LOGIN`, it is generally nevertheless good to not do history-rewriting
 stuff and the like (`git rebase` and friends), as others may in turn be basing
 their work on your private branches.
 
 We could establish a branch-tagging policy for branches that others should
 expect their history possibly to be rewritten.  This may be useful for branches
 that are only meant for aggregating the changes of (several) development
-branches, like *master-proposed_for_general_testing*.
+branches, like `master-proposed_for_general_testing`.
 
 ## Behavior in general