[PATCH 2/2] merge-recursive: preserve skip_worktree bit when necessary

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@gmail.com>
---
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(-)