+
+Whenever a new hash function textual syntax is defined, corresponding
+binary format codepoint(s) are assigned. (Detailed binary format
+specification is outside the scope of this plan.)
+
+
+ORDERING
+
+Hash functions are partially ordered, from `older' to `newer'.
+
+The ordering is configurable. The default, with the two hash
+functions defined here, is the obvious ordering
+ SHA1 ([0-9a-f]*) < BLAKE2b (H*)
+
+
+CHOICE OF OBJECT NAMES
+
+Whenever objects are named, it is possible to refer to them by old or
+new names. So git must make a choice, each time: when new objects
+are created; when refs are updated; and when refs are reported over
+network protocols to other instances of git.
+
+Although strictly speaking all objects have both old names and new
+names, and there may be more than two hash functions, it is possible
+to speak, somewhat loosely, about `new objects'.
+
+A `new' object is one which refers to other objects by a `new' name.
+(whatever `new' means).
+
+We call these different hashes `namings'. That is, a `naming' is a
+hash function implemented by git. The `naming IN an object' is the
+naming by which the object refers to other objects (and may not exist,
+if the object has no references); the `name OF an object' is the name
+by which the object itself is specified.
+
+
+Commits
+
+A non-origin commit is made (by default) as new as the newest of
+ (i) the naming in each of its parents
+ (ii) the specified name of each of its parents
+(Implicitly this normally means that if HEAD uses a new name, new
+commits will be generated.)
+
+The naming of an origin commit is controlled by a dropping left in
+.git by git checkout --orphan or git init.
+
+At boundaries between old and new history, a new commit will refer to
+old parents by those old parents' new names.
+
+
+Tags
+
+A new tag is made to use newest naming, for its tagged object, of
+ (i) the name by which the tagged object was specified
+ (ii) the naming in the tagged object (if applicable)
+
+
+Trees
+
+Commits (and sometimes, tags) can refer to tree objects; that tree
+will contain the same naming as the referring object.
+
+That is, it is a bug to refer to a tree object by other than the hash
+it uses internally to refer to subtrees (and gitlinks). This will
+mean that a tree must sometimes be rewritten (ie, new object names
+recalculated recursively).
+
+ Rationale: we want to avoid new commits and tags relying on weak
+ hashes.
+
+
+Blobs
+
+Blobs do not refer to other objects so they are neither new or old.
+
+
+Name of newly created object
+
+When git creates a new object, it reports the new object name using
+the naming in the object.
+
+For blobs and empty trees, the caller should normally specify. The
+default is the naming used for HEAD.
+
+
+Updating refs
+
+If a ref is updated with a new object, the name from its creation is
+used (see above).
+
+If a ref is updated to a specified object, the naming used in the ref
+is the newer of the specified name, or the naming in the object (if
+any).
+
+
+
+
+
+), or with a specified object name.
+
+
+
+(If there are different equally new names, one of the newest names is
+chosen according to some stable rule.)
+
+
+
+new
+
+commit. (This may mean converting the tree in hand, since trees are
+supposed to be homgeonous.)
+
+
+
+
+A `new commit' is one which refers to objects by
+
+