Daniel Barkalow <[EMAIL PROTECTED]> writes: > I've started this, and have gotten as far as having read-tree accept > 3 > trees and ignore everything but the last 3. Am I correct in assuming that > if I break read-tree in any way, some test will fail?
If some test fails you would know you broke it, but the inverse is probably not always true. I think the current read-tree test suite has reasonably wide coverage of all the interesting cases. But the definition of "interesting" was derived from the current world order (IOW, the test suite was designed around the way we do things right now as a whitebox test, not a blackbox test). I would not be surprised if some of them did not catch breakage you may introduce during the development. I wonder however if extending the current way of doing things in the cache is the right thing. Right now we use two bits out of the top four bits for recording stage, one bit for the update bit, so you have only one extra bit to extend the number of stages, which means you could hold at most 7 trees at once. You "ignore things but the last 3", so this may not be too much of a problem, but I am a bit puzzled what you meant by it though. Are you talking about reading more than 3 trees and keeping only the 3 to be merged, discarding the rest, doing the selection per path? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
