merge-recursive takes any files marked as unmerged by unpack_trees,
tries to figure out whether they can be resolved (e.g. using renames
or a file-level merge), and then if they can be it will delete the old
cache entries and writes new ones. This means that any ce_flags for
those cache entries are essentially cleared when merging.
Unfortunately, if a file was marked as skip_worktree and it needs a
file-level merge but the merge results in the same version of the file
that was found in HEAD, we skip updating the worktree (because the
file was unchanged) but clear the skip_worktree bit (because of the
delete-cache-entry-and-write-new-one). This makes git treat the file
as having a local change in the working copy, namely a delete, when it
should appear as unchanged despite not being present. Avoid this
problem by copying the skip_worktree flag in this case.
Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
---
No need to check whether pos >= 0 in this patch because the fact that
we got to this point in the code meant the entry was definitely in
both the new and old indexes (and with the same oid and mode).
We could optimize this a bit; the call to was_tracked_and_matches()
already does the lookup in o->orig_index. So we could cache that and
re-use it. Likewise, if we instead set ce_flags just after calling
make_cache_entry() within add_cacheinfo(), we could avoid looking up
the cache entry in the_index as well. Setting ce_flags there would
just require plumbing an extra flag option through add_cacheinfo() and
modifying all other callsites to pass 0 for that flag. But doing all
this felt a little messy, and I really wanted to keep the logic for
this case all in one little place. Especially for a fixup that might
be wanted for maint.
There is also another callsite in update_file_flags() that could be
updated to preserve the skip_worktree flag, which would be technically
better. But I really don't want to tackle that right now, I just want
a small simple fix for Ben's issue.
Besides, as Junio said:
"If it can be done without too much effort, then it certainly is
nicer to keep the sparseness when we do not have to materialize the
working tree file. But at least in my mind, if it needs too many
special cases, hacks, and conditionals, then it is not worth the
complexity"
merge-recursive.c | 16 ++++++++++++++++
t/t3507-cherry-pick-conflict.sh | 2 +-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 113c1d696..fd74bca17 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -3069,10 +3069,26 @@ static int merge_content(struct merge_options *o,
if (mfi.clean &&
was_tracked_and_matches(o, path, &mfi.oid, mfi.mode) &&
!df_conflict_remains) {
+ int pos;
+ struct cache_entry *ce;
+
output(o, 3, _("Skipped %s (merged same as existing)"), path);
if (add_cacheinfo(o, mfi.mode, &mfi.oid, path,
0, (!o->call_depth && !is_dirty), 0))
return -1;
+ /*
+ * However, add_cacheinfo() will delete the old cache entry
+ * and add a new one. We need to copy over any skip_worktree
+ * flag to avoid making the file appear as if it were
+ * deleted by the user.
+ */
+ pos = index_name_pos(&o->orig_index, path, strlen(path));
+ ce = o->orig_index.cache[pos];
+ if (ce_skip_worktree(ce)) {
+ pos = index_name_pos(&the_index, path, strlen(path));
+ ce = the_index.cache[pos];
+ ce->ce_flags |= CE_SKIP_WORKTREE;
+ }
return mfi.clean;
}
diff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh
index 25fac490d..9b1456a7c 100755
--- a/t/t3507-cherry-pick-conflict.sh
+++ b/t/t3507-cherry-pick-conflict.sh
@@ -392,7 +392,7 @@ test_expect_success 'commit --amend -s places the sign-off at the right place' '
test_cmp expect actual
'
-test_expect_failure 'failed cherry-pick with sparse-checkout' '
+test_expect_success 'failed cherry-pick with sparse-checkout' '
pristine_detach initial &&
git config core.sparseCheckout true &&
echo /unrelated >.git/info/sparse-checkout &&
--
2.18.0.234.g2d1e6cefb
