-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
- msg brach "commit message"
+ 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>
+ - <ref name including refs/heads/>
+ exist only in base 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 base 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
- included actual included branches, one per line
+ Files which inherit contents and changes from dependencies
+ have names starting with "+":
- flags flags that apply to this branch, one per line
- unknown flags starting with [a-z] are ok;
- otherwise fatal. Currently defined flags:
- Deleted branch is deleted
+ +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:
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
- [<email>@[<domain.name>/][<date-spec>/]<nickname-path-spec>
+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>
<date-spec> may be
<approximate date spec containing at least one ~>
- means all branches are candidates; when we come
- to select, take the branch nearest that date rather than
- the most recent; the date spec is intepreted by date -d
- after ~s have been replaced by spaces
- A prefix of the ISO8601 date spec, stopping just after a
- numeric component (or at the end)
-
-So overall, if the current branch is
+ 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 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.
~ian / topbloke.git / blobdiff