git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, benpeart@microsoft.com, kewillf@microsoft.com,
	Elijah Newren <newren@gmail.com>
Subject: [PATCH 2/2] merge-recursive: preserve skip_worktree bit when necessary
Date: Fri, 20 Jul 2018 23:34:28 -0700	[thread overview]
Message-ID: <20180721063428.20518-3-newren@gmail.com> (raw)
In-Reply-To: <20180721063428.20518-1-newren@gmail.com>

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(-)

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


  parent reply	other threads:[~2018-07-21  6:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20 19:53 [BUG] merge-recursive overly aggressive when skipping updating the working tree Ben Peart
2018-07-20 20:48 ` Elijah Newren
2018-07-20 21:13   ` Junio C Hamano
2018-07-20 21:42     ` Elijah Newren
2018-07-20 22:05       ` Junio C Hamano
2018-07-20 23:02         ` Elijah Newren
2018-07-23 12:49           ` Ben Peart
2018-07-21  6:34 ` [PATCH 0/2] Preserve skip_worktree bit in merges when necessary Elijah Newren
2018-07-21  6:34   ` [PATCH 1/2] t3507: add a testcase showing failure with sparse checkout Elijah Newren
2018-07-21  7:21     ` Eric Sunshine
2018-07-23 13:12       ` Ben Peart
2018-07-23 18:09         ` Eric Sunshine
2018-07-23 18:22           ` Ben Peart
2018-07-21 13:02     ` Ben Peart
2018-07-23 18:12       ` Junio C Hamano
2018-07-21  6:34   ` Elijah Newren [this message]
2018-07-23 14:14     ` [PATCH 2/2] merge-recursive: preserve skip_worktree bit when necessary Ben Peart
2018-07-27 12:59 ` [PATCH v2 0/2] Preserve skip_worktree bit in merges " Ben Peart
2018-07-27 12:59   ` [PATCH v2 1/2] t3507: add a testcase showing failure with sparse checkout Ben Peart
2018-07-27 12:59   ` [PATCH v2 2/2] merge-recursive: preserve skip_worktree bit when necessary Ben Peart
2018-07-27 18:14   ` [PATCH v2 0/2] Preserve skip_worktree bit in merges " Junio C Hamano
2018-07-31 16:11   ` Elijah Newren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180721063428.20518-3-newren@gmail.com \
    --to=newren@gmail.com \
    --cc=benpeart@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kewillf@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).