Re: [PATCHv2 3/3] merge-recursive: When we detect we can skip an update, actually skip it

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 2, 2011, 20:19 UTC
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:

Show 13 quoted lines

> @@ -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?