Re: [PATCH] threeway_merge: if file will not be touched, leave it alone
- From
Junio C Hamano <junkio@cox.net>
- Date
- Oct 22, 2006, 23:11 UTC
- Message-ID
- <7vlkn80wv2.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.63.0610222301080.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 24 quoted lines
> 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.