Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html