All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: Jonathon Mah <me@JonathonMah.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Bug: write-tree corrupts intent-to-add index state
Date: Tue, 6 Nov 2012 19:37:34 +0700	[thread overview]
Message-ID: <20121106123734.GA11836@lanh> (raw)
In-Reply-To: <3E62F933-76CD-4578-8684-21444EAA454F@JonathonMah.com>

On Tue, Nov 06, 2012 at 12:53:27AM -0800, Jonathon Mah wrote:
> It appears the index forgot that those files were new. So not only
> has the intent-to-add status been lost, but git status shows a file
>  existing in neither HEAD nor the index as not-new-but-modified.
>
> Tracing through it, I narrowed it down to git write-tree affecting
> the index state. As far as I can tell, it's incorrect for that
> command to change the index. I'm now out of my (shallow) depth in
> the git codebase, so I'm throwing it out there for someone to tackle
> (hopefully). I've attached a failing test case.

I played with your test a bit and found that if we skip the commit
step, the bug disappears. I checked and believe that i-t-a flag in
index is preserved, which leaves cache-tree as the culprit. If
cache-tree is (incorrectly) valid, diff operations won't bother
checking index.

We used to not allow writing tree with i-t-a entries present. Then we
allowed it, but forgot that we need to invalidate any paths that
contain i-t-a entries, otherwise cache-tree won't truly reflect
index.

The below patch seems to do the trick, but I'd rather do the
invalidation inside update_one() so we don't need to traverse over the
index again. I haven't succesfully put cache-tree.c back in my head
again to make it happen. Anybody is welcome to step up, or I'll finish
it this weekend.

-- 8< --
diff --git a/cache-tree.c b/cache-tree.c
index 28ed657..30a8018 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it,
 	i = update_one(it, cache, entries, "", 0, flags);
 	if (i < 0)
 		return i;
+	for (i = 0; i < entries; i++)
+		if (cache[i]->ce_flags & CE_INTENT_TO_ADD)
+			cache_tree_invalidate_path(it, cache[i]->name);
 	return 0;
 }
 
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index ec35409..3ddbd89 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -62,5 +62,25 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
 	git commit -a -m all
 '
 
+test_expect_success 'cache-tree invalidates i-t-a paths' '
+	git reset --hard &&
+	mkdir dir &&
+	: >dir/foo &&
+	git add dir/foo &&
+	git commit -m foo &&
+
+	: >dir/bar &&
+	git add -N dir/bar &&
+	git diff --cached --name-only >actual &&
+	echo dir/bar >expect &&
+	test_cmp expect actual &&
+
+	git write-tree >/dev/null &&
+
+	git diff --cached --name-only >actual &&
+	echo dir/bar >expect &&
+	test_cmp expect actual
+'
+
 test_done
-- 8< -- 

  reply	other threads:[~2012-11-06 12:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-06  8:53 Bug: write-tree corrupts intent-to-add index state Jonathon Mah
2012-11-06 12:37 ` Nguyen Thai Ngoc Duy [this message]
2012-11-09 11:04 ` [PATCH] cache-tree: invalidate i-t-a paths after writing trees Nguyễn Thái Ngọc Duy
2012-11-09 11:57   ` Junio C Hamano
2012-11-10 11:04     ` Nguyen Thai Ngoc Duy
2012-11-30  0:06       ` Junio C Hamano
2012-11-30  1:26         ` Nguyen Thai Ngoc Duy
2012-12-08  4:10   ` [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees Nguyễn Thái Ngọc Duy
2012-12-10  6:50     ` Junio C Hamano
2012-12-10 11:53       ` Nguyen Thai Ngoc Duy
2012-12-10 17:22         ` Junio C Hamano
2012-12-13  1:39           ` [PATCH v3 1/2] " Nguyễn Thái Ngọc Duy
2012-12-13  1:39             ` [PATCH v3 2/2] cache-tree: remove dead i-t-a code in verify_cache() Nguyễn Thái Ngọc Duy
2012-12-13 18:34               ` Junio C Hamano
2012-12-13  2:04             ` [PATCH v3 1/2] cache-tree: invalidate i-t-a paths after generating trees Junio C Hamano
2012-12-15  2:52               ` Nguyen Thai Ngoc Duy

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=20121106123734.GA11836@lanh \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@JonathonMah.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.