All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
To: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Jonathan Niedier <jrnieder@gmail.com>
Cc: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: [PATCH 2/5] unpack-trees: only clear CE_UPDATE|CE_REMOVE when skip-worktree is always set
Date: Sat, 31 Jul 2010 13:14:26 +0700	[thread overview]
Message-ID: <1280556869-707-3-git-send-email-pclouds@gmail.com> (raw)
In-Reply-To: <1280556869-707-1-git-send-email-pclouds@gmail.com>

The purpose of this clearing is, as explained in comment, because
verify_*() may set those bits before apply_sparse_checkout() is
called. By that time, it's not clear whether an entry will stay in
checkout area or out. After $GIT_DIR/info/sparse-checkout is applied,
we know what entries will be in finally. It's time to clean unwanted
bits.

That works perfectly when checkout area remains unchanged. When
checkout area changes, apply_sparse_checkout() may set CE_UPDATE
or CE_WT_REMOVE to widen/narrow checkout area. Doing the clearing
after apply_sparse_checkout() may clear those widening/narrowing
bits unexpectedly.

So, only do that on entries that are not affected by checkout area
changes (i.e. skip-worktree bit does not change after
apply_sparse_checkout).

This code does not actually fix anything though, just
future-proof. The removed code and the narrow/widen code inside
apply_sparse_checkout are currently independent (narrow code never
sets CE_REMOVE, widen code sets CE_UPDATE, but ce_skip_worktree()
would be false).

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 t/t1011-read-tree-sparse-checkout.sh |   12 ++++++++++++
 unpack-trees.c                       |   26 ++++++++++++--------------
 2 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/t/t1011-read-tree-sparse-checkout.sh b/t/t1011-read-tree-sparse-checkout.sh
index 9189de8..2876daf 100755
--- a/t/t1011-read-tree-sparse-checkout.sh
+++ b/t/t1011-read-tree-sparse-checkout.sh
@@ -155,4 +155,16 @@ test_expect_success 'read-tree adds to worktree, dirty case' '
 	grep -q dirty sub/added
 '
 
+test_expect_success 'index removal and worktree narrowing at the same time' '
+	>empty &&
+	echo init.t >.git/info/sparse-checkout &&
+	echo sub/added >>.git/info/sparse-checkout &&
+	git checkout -f top &&
+	echo init.t >.git/info/sparse-checkout &&
+	git checkout removed &&
+	git ls-files sub/added >result
+	test ! -f sub/added &&
+	test_cmp empty result
+'
+
 test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index e8f03f5..6d0df99 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -156,13 +156,18 @@ static int apply_sparse_checkout(struct cache_entry *ce, struct unpack_trees_opt
 		ce->ce_flags &= ~CE_SKIP_WORKTREE;
 
 	/*
-	 * We only care about files getting into the checkout area
-	 * If merge strategies want to remove some, go ahead, this
-	 * flag will be removed eventually in unpack_trees() if it's
-	 * outside checkout area.
+	 * if (!was_skip_worktree && !ce_skip_worktree()) {
+	 *	This is perfectly normal. Move on;
+	 * }
 	 */
-	if (ce->ce_flags & CE_REMOVE)
-		return 0;
+
+	/*
+	 * Merge strategies may set CE_UPDATE|CE_REMOVE outside checkout
+	 * area as a result of ce_skip_worktree() shortcuts in
+	 * verify_absent() and verify_uptodate(). Clear them.
+	 */
+	if (was_skip_worktree && ce_skip_worktree(ce))
+		ce->ce_flags &= ~(CE_UPDATE | CE_REMOVE);
 
 	if (!was_skip_worktree && ce_skip_worktree(ce)) {
 		/*
@@ -796,14 +801,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
 				ret = -1;
 				goto done;
 			}
-			/*
-			 * Merge strategies may set CE_UPDATE|CE_REMOVE outside checkout
-			 * area as a result of ce_skip_worktree() shortcuts in
-			 * verify_absent() and verify_uptodate(). Clear them.
-			 */
-			if (ce_skip_worktree(ce))
-				ce->ce_flags &= ~(CE_UPDATE | CE_REMOVE);
-			else
+			if (!ce_skip_worktree(ce))
 				empty_worktree = 0;
 
 		}
-- 
1.7.1.rc1.69.g24c2f7

  parent reply	other threads:[~2010-07-31  6:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-31  6:14 [PATCH 0/5] nd/fix-sparse-checkout v2 Nguyễn Thái Ngọc Duy
2010-07-31  6:14 ` [PATCH 1/5] t1011 (sparse checkout): style nitpicks Nguyễn Thái Ngọc Duy
2010-08-02 17:22   ` Junio C Hamano
2010-08-02 17:31     ` Junio C Hamano
2010-07-31  6:14 ` Nguyễn Thái Ngọc Duy [this message]
2010-08-08 22:39   ` [PATCH 2/5] unpack-trees: only clear CE_UPDATE|CE_REMOVE when skip-worktree is always set Jonathan Nieder
2010-07-31  6:14 ` [PATCH 3/5] unpack-trees: let read-tree -u remove index entries outside sparse area Nguyễn Thái Ngọc Duy
2010-07-31  6:14 ` [PATCH 4/5] unpack-trees: do not check for conflict entries too early Nguyễn Thái Ngọc Duy
2010-07-31  6:14 ` [PATCH 5/5] unpack-trees: mark new entries skip-worktree appropriately Nguyễn Thái Ngọc Duy
2010-08-03 21:16 ` [PATCH 0/5] nd/fix-sparse-checkout v2 Jonathan Nieder

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

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

  git send-email \
    --in-reply-to=1280556869-707-3-git-send-email-pclouds@gmail.com \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.