From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 02 Mar 2011 20:19:03 GMT
Subject: Re: [PATCHv2 3/3] merge-recursive: When we detect we can skip an update, actually skip it
Message-ID: <7vwrkhb7ig.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1298941732-19763-4-git-send-email-newren@gmail.com>

Elijah Newren <newren@gmail.com> writes:

> @@ -1274,9 +1275,13 @@ static int merge_content(struct merge_options *o,
>  	}
>  
>  	if (mfi.clean && !df_conflict_remains &&
> -	    sha_eq(mfi.sha, a_sha) && mfi.mode == a.mode)
> +	    sha_eq(mfi.sha, a_sha) && mfi.mode == a.mode &&
> +	    lstat(path, &st) == 0) {
>  		output(o, 3, "Skipped %s (merged same as existing)", path);
> -	else
> +		add_cacheinfo(mfi.mode, mfi.sha, path,
> +			      0 /*stage*/, 1 /*refresh*/, 0 /*options*/);
> +		return mfi.clean;
> +	} else

Hmmmm.  During a merge, we allow files missing from the working tree as if
it is not modified from the index.  Changing the behaviour based on the
existence of the path on the filesystem does not feel quite right.

Even if we decide that regressing in that use case were acceptable, what
guarantees that the path that happens to be in the work tree has the same
contents as what the merge result should be?  IOW, shouldn't we be looking
at the original index, making sure that our side (stage #2) at the path
had a file there that matches the merge result mfi.{sha,mode}, instead of
looking at the working tree?