chiark / gitweb /
DESIGN: mention topgit a couple more times
[topbloke.git] / DESIGN
diff --git a/DESIGN b/DESIGN
index 66003b3c74b20ad61dcd50a4c16b24b7f02b7cc7..57f3191e23f1282d5b76fc75dd9084128071a52a 100644 (file)
--- a/DESIGN
+++ b/DESIGN
@@ -17,7 +17,8 @@ Basic update algorithm:
     ii. For each source in the best order, do the following merge:
         (Our base has sources:
             - the branch for each direct dep
-            - the remote base)
+            - the remote base
+           - the topgit base, if this is a topgit import)
 
        Find the (latest) common ancestor.
 
@@ -86,12 +87,14 @@ Basic update algorithm:
          * Attempt to apply the appropriate diff to add (resp. remove)
            the contents of the relevant patch (adjusted appropriately
            for metadata, XXX??? particularly the actual inclusion list)
+          XXX if we want to add a dep we need to update the dep first
          * Go round again looking for another discrepancy.
 
  3. Update our branch.
        Our branch has sources:
           - our base
           - the remote for our branch
+          - the topgit branch, if this is a topgit import
        For each source in the best order, do the merge.
 
        Double-check the actual dependency inclusions.  In
@@ -196,3 +199,42 @@ Or something.
 Have discovered that specifying a custom merge driver for a file does
 not have any effect if the three-way-merge looks trivial based
 on looking at the file contents - at least, if you use git-merge.
+
+Only thing which knows how to do all the gitattributes stuff and
+conflict markers and what have you is git-merge.  (git-merge-tree does
+too but the output format is unsuitable.)  "git-merge-index
+... git-merge-one-file" does not honour the merge drivers and is,
+contrary to what the git docs seem to suggest but don't actually
+state, not actualy used by git-merge.
+
+OK so here is a plan:
+  Use git-merge --no-commit
+  Perhaps on a HEAD, and/or against a tree, which have been massaged
+   to make the metadata suitable as input.
+  Filtering out the "merge was successful but we aren't committing"
+  message.  Use a single pipe for stdout/stderr to get interleaving
+  right; the message from git-merge is not i18n'd.
+  Afterwards we:
+  Check for merge success in the index and compare to exit status
+  from git-merge (which is 1 if the merge failed).
+  Adjust the metadata.
+  Print appropriate big fat warnings if we have merge conflicts in our 
+  metadata.
+  Commit, adjusting the parents of the new commit to the original
+  parents if we made the merge with special massaged parents.
+  We may still need to have custom merge drivers for metadata.
+
+
+Strategies for each metadata file merge:
+
+       in base/tip     same patch's tip        dep -> base     base -> tip
+
+ msg            T      textual merge           rm from src     not in src
+ deps           T      list merge              rm from src     not in src
+ deleted        T      std existence merge     rm from src     not in src
+ patch-                BT      must be same            rm from src     must be same
+ topgit-        T      must be same            rm from src     not in src
+ [^+]*-                ??      textual merge           rm from src     rm from src
+ +included     BT      list merge        rm from non-tb src    list merge
+ +*-           ??      textual merge     rm from non-tb src    textual merge
+ *[^-]         ??      die, aborting all ops, if found in any tb src or branch