Re: Broken adding of cache entries

From: Petr Baudis <pasky@ucw.cz>
Date: May 7, 2005, 22:41 UTC
Message-ID: <20050507224116.GF9495@pasky.ji.cz>
In-Reply-To: <7vhdhealjm.fsf@assigned-by-dhcp.cox.net>

Dear diary, on Sat, May 07, 2005 at 09:22:21PM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Show 7 quoted lines

> Kay Sievers noticed that you can have both path and path/file in
> the cache and write-tree happily creates a tree object from such
> a state.  Since a merge can result in such situation and the
> user should be able to see the situation by looking at the
> cache, rather than forbidding add_cache_entry() to create such
> conflicts, fix it by making write-tree refuse to write such an
> nonsensical tree.

I'd still prefer add_cache_entry() to just replace the original entry (as it does otherwise). Only make it to care about which stage it is working in, to make merges to work. IOW, I think you are solving this at the wrong workflow point. It is too "late" to know at that point, and (a huge) PITA for the higher levels to deal with it then - that all when it shouldn't fail _at all_ in the first place.

What about

--- b7ae63ab415e556c2f0f0ad2803f701b4a6d6956/read-cache.c (mode:100644) +++ uncommitted/read-cache.c (mode:100644)

@@ -68,9 +68,9 @@
                return -1;
        if (len1 > len2)
                return 1;
-       if (flags1 < flags2)
+       if (flags1 & CE_STAGEMASK < flags2 & CE_STAGEMASK)
                return -1;
-       if (flags1 > flags2)
+       if (flags1 & CE_STAGEMASK > flags2 & CE_STAGEMASK)
                return 1;
        return 0;
 }

then? (Completely untested and everything.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor