From 4a54766a2027a9c9bdeacc84e1a645a4ad60b571 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Sun, 29 Jan 2012 20:37:28 +0000 Subject: [PATCH] Results of testing git merging --- DESIGN | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/DESIGN b/DESIGN index 66003b3..036cbec 100644 --- 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. -- 2.30.2