Elijah Newren <newren@xxxxxxxxx> 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?
--
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