X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ian/git?a=blobdiff_plain;f=DESIGN;h=e62456b7bbcbf5cdeceb77b4fa1838442c0029a2;hb=5e27959c9cf017851d9483a8ec43ed45dabc9c19;hp=b1c06ebcfc3013c5ac391a027b7d6d1f7f202646;hpb=5f8bef88e705fa42e51f6209857a81a8f6f97745;p=topbloke.git

diff --git a/DESIGN b/DESIGN
index b1c06eb..e62456b 100644
--- a/DESIGN
+++ b/DESIGN
@@ -116,6 +116,8 @@ Actual included branches:
   which do not support dependency deletion, always have exactly the
   desired branches actually included.)
 
+  Non-topbloke-controlled branches are never recorded in included.
+
 
 Branch removal:
 
@@ -125,8 +127,8 @@ Branch removal:
 
  - removed branch wants not to be in list of branches "git-branch"
    et al any more
-      branches in refs/top-branches ?
-      deleted branches do something to the base ?
+      branches in refs/top-branches ?  yes
+      deleted branches do something to the base ?  no
 
  deleting empty branch: dependencies fine
  deleting nonempty branch: if any dependencies found, their
@@ -138,10 +140,12 @@ Branch removal:
    - remove from dependencies of active branches
        only makes sense if no active branches depend on it.
 
+ undeleting
+   - just unmark the branch as deleted
+
 Branch naming:
  needs to be globally unique
  so put email address in it
- also "tree" or "context" name, found automatically
 tg operations search for applicable branches
 safe charset for branch names
   . - / 0-9 a-z
@@ -149,3 +153,21 @@ not permitted (git-check-ref-format(1))
  spc ~ ^ : ? * [ \
  @{ .lock.
  (apropos of shell)
+
+
+When pulling, which remotes get to update which branches ?
+Complicated question!
+
+For now, have "blessed" remotes, which we always pull and update from.
+All these count as sources above.
+
+Update operation restrictions available, which restrict use of various
+sources above ?  What about implications for correctness of merge
+algorithm ?
+
+
+Concept of a "stack" ?
+Unnecessary - instead, deal with leaf branches
+Operations like "go up the stack", goes towards leaf.  Hopefully unique.
+"Down" the stack, uses a "conventional" linearisation
+Stack reordering op ?  auto adjust deps