Results of testing git merging

[topbloke.git] / DESIGN

diff --git a/DESIGN b/DESIGN
index 66003b3c74b20ad61dcd50a4c16b24b7f02b7cc7..036cbec757ab4ee966798c1fd2ffb9cc36b001fc 100644 (file)
--- a/DESIGN
+++ b/DESIGN
@@ -196,3 +196,27 @@ 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.