Re: [RFC] Looking at multiple ancestors in merge

[Junio C Hamano <junkio@cox.net>]

Daniel Barkalow <barkalow@iabervon.org> 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?