include images for contrib/branching

docs/contrib/branching.md

@@ -13,7 +13,7 @@ Taskwarrior and Taskserver use the same branching model.
 Git allows arbitrary and low-cost branching, which means that any branching model can be used.
 A new Git repository has one branch, the default branch, named `master`, but even this is not required.
 
-[![master](/docs/images/master.png)](/docs/images/master.png)
+[![master](master.png)](master.png)
 
 No development occurs on the `master` branch.
 
@@ -24,7 +24,7 @@ A development branch is created from the `master` branch, and work proceeds on t
 Development branches are pushed to the server.
 Note that there are no changes on `master` - all work is done on dev branches.
 
-[![dev](/docs/images/dev.png)](/docs/images/dev.png)
+[![dev](dev.png)](dev.png)
 
 All work on dev branches is pushed to the server.
 
@@ -36,7 +36,7 @@ This can be a useful way to manage parallel efforts on a single development mach
 Topic branches are also useful for merging in submitted patches, because the patch can be merged, tested and corrected independently of other efforts before being merged and pushed.
 A topic branch is ideal for storage of changes before an eventual merge back to the development branch.
 
-[![topic](/docs/images/topic.png)](/docs/images/topic.png)
+[![topic](topic.png)](topic.png)
 
 No topic branches are pushed to the server, they are kept local to the development machine.
 They are private, and therefore hidden from the server.
@@ -46,7 +46,7 @@ They are private, and therefore hidden from the server.
 
 When a release is made, the development branch is merged back to the `master` branch, and a tag is applied that indicates which commit represents the release.
 
-[![release](/docs/images/release.png)](/docs/images/release.png)
+[![release](release.png)](release.png)
 
 Because only releases are merged back, the `master` branch always represent the stable release.
 
@@ -63,7 +63,7 @@ The second branch, with the higher release number is the development branch for
 This is where all the work occurs.
 Any fix made on the development branch can be cherry-picked onto the patch branch, if necessary.
 
-[![dev2](/docs/images/dev2.png)](/docs/images/dev2.png)
+[![dev2](dev2.png)](dev2.png)
 
 To address the confusion around branching, namely determining which branch is active.
 the answer is that the highest numbered branch is the one that patches should be applied to.

docs/rfcs/protocol.md

@@ -74,25 +74,25 @@ Each task SHALL have a 'modified' date attribute that will help resolve conflict
 
 On sync:
 
--   Send a 'sync' type message with the entire contents of the backlog.data, unmodified, as the message payload.
+*   Send a 'sync' type message with the entire contents of the backlog.data, unmodified, as the message payload.
 
--   Receive one of the following response codes:
+*   Receive one of the following response codes:
 
-  -   201: This means 'no change', and there is no further action to be taken.
+  *   201: This means 'no change', and there is no further action to be taken.
 
-  -   200: This means 'success', and the message payload contains a set of tasks and a sync key:
+  *   200: This means 'success', and the message payload contains a set of tasks and a sync key:
 
-    -   The formatted tasks are to be stored as-is.
+    *   The formatted tasks are to be stored as-is.
         These tasks will either be appended to the client data or will overwrite existing client data, based on the UUID of the task.
         No merge logic is necessary.
 
-    -   The sync key will be written to the backlog.data file, overwriting the previous contents, such that it will now contain only one line.
+    *   The sync key will be written to the backlog.data file, overwriting the previous contents, such that it will now contain only one line.
 
-    -   301: Redirect to : found in the 'info' response header, will force the client to resubmit the request to the new server.
+    *   301: Redirect to : found in the 'info' response header, will force the client to resubmit the request to the new server.
 
-    -   3xx, 4xx, 5xx: The 'status' field contains an error message.
+    *   3xx, 4xx, 5xx: The 'status' field contains an error message.
 
--   If the response contained any error or warning, the error should be shown to the user.
+*   If the response contained any error or warning, the error should be shown to the user.
     This provides an opportunity for the server to announce downtime, or relocation.
 
 If no sync key is sent, the server cannot provide an incremental delta, and so will send all task data, which should be stored as above.