Fix various issues with Markdown docs

docs/shift_based_development.md

 # Introduction
 
 Kai Wang (kaiwang@) and I (Jói Sigurðsson, joi@) experimented with something we called “shift-based development” in the first half of Q1 2013 as a way to work closely together on a componentization that was hard to do in parallel.
 
 I work from Iceland, which is 7 or 8 hours ahead of Kai’s location (Mountain View, California), depending on the time of year (daylight savings time is not observed in Iceland). Kai and I were working on componentizing the Prefs subsystem of Chromium, and it was obvious early on that if we tried to develop in parallel, we would step on each others’ toes very regularly and be forced to do often difficult merges (due to e.g. moving files, renaming things, and so on). The idea came up, since my normal work day ends right around the time Kai’s starts, why not do the development in serial instead. Although I often work an extra hour or two later in the evening, that’s normally for responding to code review requests and email and not so much for coding, so this way we’d be completely free of getting in each others’ way.
 
 The way we implemented this was we set up a bare git repository, and at the end of the day, we would push whatever we were working on to this repository, and let the other know the status of things. This could be a single working branch, or (more often) a pipeline of branches, plus a branch representing the SVN revision we were based off of. To make this work, we were both using the unmanaged git workflow.
 
 The idea was, the next “shift” would pull down the pipeline of branches and continue where the last left off, doing development on the last change in the pipeline if it was incomplete, landing whatever changes could be landed, or starting a new change in the pipeline if all of them were ready for review or ready to land.
 
@@ skipping 40 matching lines @@
 $ git add boo.txt && git commit -m .
 $ git push shiftrepo
 ```
 
 The shared repository is just a place where you share your branches;
 it is not a place where you do actual work.  The actual work should be
 done in your separate local repositories, and you still use e.g. git
 pull (which in our git svn repositories behind the scenes does a `git svn fetch` etc.
 
 Shift-based collaboration won't work well (at least not with a
-pipeline of branches) unless you are using an "unmanaged" git checkout
-(search for "unmanaged" on
-[this page](https://code.google.com/p/chromium/wiki/UsingNewGit)).
+pipeline of branches) unless you are using an "unmanaged" git checkout.
 
 ## Example Working Rules
 
 For the branches we collaborated on, we set up some working
 rules. This may be a good starting set and it worked well enough for us,
 but others could adapt these rules:
 
 a) We had a naming convention for pipelines of branches. E.g. you
 might have branches named shiftrepo/p0-movemore and shiftrepo/p1-sync,
 where p1-sync's upstream branch is p0-movemore, and p0-movemore's
@@ skipping 68 matching lines @@
 currently-open branches, and to discuss what might make sense for the
 next branches to work on.
 
 ## Random Commands
 
 To push a local branch to shiftrepo: `git push shiftrepo localbranchname`
 
 To push all "matching" branches (i.e. push the latest copy of
 any local branch that has previously been pushed to shiftrepo): `git push shiftrepo`
 
-To delete a branch from shiftrepo, it's weird: `git push shiftrepo :branchname`
+To delete a branch from shiftrepo, it's weird: `git push shiftrepo :branchname`