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; - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
