-\section{Strategy}
-
-When we are trying to do a merge of some kind, in general,
-we want to merge some commits $S_0 \ldots S_n$.
-We'll write $S_0 = L$. We require that $L$ is the current git ref
-for $\patchof{L}$.
-
-%Let $\set E_{\pc} = \bigcup_i \pendsof{S_i}{\pc}$.
-
-\subsection{Notation}
+Here we describe the update algorithm. This is responsible for
+refreshing patches against updated versions of their dependencies,
+for merging different versions of the various braches created by
+distributed development, and for implementing decisions to add and
+remove dependencies from patches.
+
+Broadly speaking the update proceeds as follows: during the Ranking
+phase we construct the intended graph of dependencies between patches
+(and incidentally select a merge order for the base branch of each
+patch). Then during the Traversal phase we walk that graph from the
+bottom up, constructing for each patch by a series of merges and other
+operations first a new base branch head commit and then a new tip
+branch head commit. These new head commits are maximums - that is,
+each has as ancestors all of its branches' sources and indeed all
+relevant commits in that branch.
+
+We have two possible strategies for constructing new base branch
+heads: we can either Merge (works incrementally even if there the
+patch has multiple dependencies, but may sometimes not be possible) or
+we can Regenerate (trivial if there is a single dependency, and is
+always possible, but may involve the user re-resolving conflicts if
+there are multiple dependencies).
+
+\section{Notation}