-Topbloke branch is:
+Topbloke patch is:
- branch in refs/topbloke-tips/<full-name>
contains the working version, fast-forwarding
- branch in refs/topbloke-bases/<full-name>
In-tree, there are metadata files in .topbloke
- Files which are per-branch and do not inherit any contents
+ Files which are per-patch and do not inherit any contents
or changes from bases or dependencies:
- msg brach "commit message"
+ msg patch "commit message"
("# not applicable" in bases)
deps direct dependencies, one per line
as either:
- topbloke branch name
- /refs/heads/<something>
- ("# not applicable" in bases)
-
- flags flags that apply to this branch, one per line
- base has its own, perhaps different, set of flags;
- Unknown flags starting with [a-z] are ok;
- otherwise fatal. Currently defined flags:
- Deleted branch is deleted
- (valid on branch only)
+ <topbloke patch name>
+ .f <ref name including refs/heads/>
+ .tg <ref name not including refs/heads/>
+ (empty in base branches)
+
+ props properties that apply to this patch, one per line
+ in the format "<name>[ <value>]" (exactly one
+ space) where value can contain spaces and
+ a missing value is distinct from a missing property
+ but value if present must be nonempty
+ base has its own, perhaps different, set of props;
+ Unknown props starting with [a-z] are ok;
+ otherwise fatal. Currently defined props:
+ patch <name> topbloke patch name (in tip and base)
+ topgit <name> this is a topgit import (in tip and base)
+ Deleted patch is deleted (in tip only, no value)
Files which not inherit contents and changes from dependencies:
- included actual included branches, one per line
- topbloke branch name
+ included actual included deps, one per line
+ format as for deps
- pflags flags that apply to this branch and all its
- dependencies (ie, flags that propagate)
- Unknown flags starting with [a-z] are ok;
- otherwise fatal. No currently defined flags
+ pprops properties that apply to this patch and all its
+ dependencies (ie, properties that propagate)
+ Unknown props starting with [a-z] are ok;
+ otherwise fatal. No currently defined props.
<full-name> has the format:
ijackson@chiark.greenend.org.uk/2012-01-20T225127Z/reorg/sponge
NB only exactly that date format is allowed and timezone must be Z.
-Branches may be specified as
- [<qualifier>/...]<nickname-path-spec>
+Patches may be specified as
+ [<qualifier>/...][<nickname-path-spec>]
where <qualifier>/ is one of
[<email>]@[<domain.name>/
- Only branches matching the specified email local part
+ 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 branch
+ spaces. When we come to select, take the patch
nearest that date rather than the most recent
<date-spec> may be
<approximate date spec containing at least one ~>
- means all branches are candidates
+ means all patches are candidates
-So overall, if the current branch is
+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 branch
+then all of the following can refer to the same patch
./sponge
../reorg/sponge
reorg/sponge
ijackson@chiark.greenend.org.uk/2012-01-20T225127Z/reorg/sponge
Search algorithm:
- 1. prefer branches with email address (or domain)
- matching current branch
- 2. prefer branches with our own email address (or domain)
- 3. other branches
-Within this there may be branches with multiple dates; prefer the most
+ 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.