Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 21, 2008, 19:09 UTC
Message-ID: <alpine.LFD.1.00.0801211104590.2957@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.1.00.0801211022350.2957@woody.linux-foundation.org>

On Mon, 21 Jan 2008, Linus Torvalds wrote:

> 
> Will experiment more now that I have a case that reliably fails. The 
> commit that causes this literally shouldn't have caused any semantic 
> changes at all, so this is rather interesting.

Intriguing. It's the "ce_mode" -> CE_REMOVE changes that trigger this bug.

The problem goes away with this one-liner.

I haven't figured out *why*, yet, but the reason I checked CE_REMOVE was that it was the only part that wasn't just a pure network order change.

I suspect we have some code-path that didn't check for explicit removal, but that happened to check for "mode doesn't match", so clearing ce_mode just magically triggered it.

Still looking.

		Linus

---

diff --git a/unpack-trees.c b/unpack-trees.c
index ff46fd6..d6fcf60 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -613,6 +613,7 @@ static int deleted_entry(struct cache_entry *ce, struct cache_entry *old,
 	else
 		verify_absent(ce, "removed", o);
 	ce->ce_flags |= CE_REMOVE;
+	ce->ce_mode = 0;
 	add_cache_entry(ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
 	invalidate_ce_path(ce);
 	return 1;