Topbloke patch is:
	- branch in refs/topbloke-tips/<full-name>
		contains the working version, fast-forwarding
	- branch in refs/topbloke-bases/<full-name>
		contains the base version, being the pulling
		merge of all the bases

In-tree, there are metadata files in .topbloke

    Files which are per-patch and do not inherit any contents
    or changes from bases or dependencies:

	msg		patch "commit message"
			exist only in tip branch

	deps		direct dependencies, one per line
			as either:
				<topbloke patch name>
				.f <ref name including refs/heads/>
				.tg <ref name not including refs/heads/>
			exist only in tip branch

	deleted		exists (but empty) if branch is deleted
			exist only in tip branch

	patch-		name of this topbloke patch (plus a newline)
			exists in base and tip, identical value

	topgit-		name of the topgit branch that this was
			imported from and which we should merge from
			(plus a newline)
			exist only in tip branch

	[^+]*-		another property that applies to this patch;
			if not known to this version of topbloke then it
			is safe to:
			  - merge this file as text when merging
			    from base into base, or tip into tip,
			    and perhaps ask user to fix up conflicts
			    after warning if they feel expert
			  - throw away this file when merging from
			    from dep into base or base into tip

    Files which inherit contents and changes from dependencies
    have names starting with "+":

	+included	actual included deps, one per line
			format as for deps
			exists in tip and base branches

	+*-		another property that is inherited; it is also
			safe to:
			 - merge this file as text when merging
			   from tb dep into base, base into tip
			   or tip into tip

    Any unknown metadata files not ending in "-" are fatal: tb
    will refuse to operate on patches either of whose branches
    have such files.


<full-name> has the format:
	<email>@<domain.name>/<yyyy>-<mm>-<dd>T<hh><mm><ss>Z/<nickname-path>
where nickname-path's first component must not start with a digit 
contain ~ or @  (: is not allowed in refs hence the squashing)
eg
	ijackson@chiark.greenend.org.uk/2012-01-20T225127Z/reorg/sponge
NB only exactly that date format is allowed and timezone must be Z.

Patches may be specified as
	[<qualifier>/...][<nickname-path-spec>]
where <qualifier>/ is one of
	[<email>]@[<domain.name>/
		Only patches matching the specified email local part
		or domain name match
	[<date-spec>/]
		A prefix of the ISO8601 date spec, stopping
		just after a numeric component (or at the end)
	[<approx-date-containing-~>/]
		Intepreted by date -d after ~s have been replaced by
		spaces.  When we come to select, take the patch
		nearest that date rather than the most recent


<nickname-path-spec> may be
	<nickname-path>
	./<nickname-new-leaf-component>
	../<nickname-path-spec>

<date-spec> may be
	<approximate date spec containing at least one ~>
		means all patches are candidates

So overall, if the current patch is
	ijackson@chiark.greenend.org.uk/2011-08-20T120320Z/fixes/pudding
then all of the following can refer to the same patch
	./sponge
	../reorg/sponge
	reorg/sponge
	2012/reorg/sponge
	2012/reorg/sponge
	2012/./sponge
	jan~/./sponge
	ijackson@/reorg/sponge
	ijackson@/2012/reorg/sponge
	ijackson@chiark.greenend.org.uk/reorg/sponge
	ijackson@chiark.greenend.org.uk/2012-01-20T225127Z/reorg/sponge

Search algorithm:
	1. prefer patches with email address (or domain)
	   matching current patch
	2. prefer patches with our own email address (or domain)
	3. other patches
Within this there may be patches with multiple dates; prefer the most
recent.