Re: [PATCH] threeway_merge: if file will not be touched, leave it alone
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:45
Possibly related (same subject, not in this thread)
- 2016-06-15 · [PATCH] threeway_merge: if file will not be touched, leave it alone · Johannes Schindelin <hidden>
- 2016-06-15 · Re: [PATCH] threeway_merge: if file will not be touched, leave it alone · Junio C Hamano <hidden>
Johannes Schindelin [off-list ref] writes:
quoted hunk
How about this? It passes the testsuite, and I tested it with the test case you did, and with the same test case with recursive merge. unpack-trees.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-)diff --git a/unpack-trees.c b/unpack-trees.c index 3ac0289..b4994c4 100644 --- a/unpack-trees.c +++ b/unpack-trees.c@@ -658,10 +658,9 @@ int threeway_merge(struct cache_entry ** * up-to-date to avoid the files getting overwritten with * conflict resolution files. */ - if (index) { + if (index) verify_uptodate(index, o); - } - else if (path) + else if (no_anc_exists) verify_absent(path, "overwritten", o); o->nontrivial_merge = 1;
This feels wrong at the philosophical level. unpack-trees and read-tree do not know, and more importantly, do not want to decide, the outcome of the merge, so it should not be doing verify_absent because it does not know if the path will be overwritten by the merge. Complaining when no_anc_exists means that threeway_merge() is deciding that the merge result should have the path in this case. It might be true for the current merge-recursive and merge-resolve, but I do not think we should force that decision on future merge strategies, since that is the whole point of declaring the merge to be nontrivial and _not_ deciding the outcome ourselves here.