On Fri, Jul 15, 2011 at 02:04:06PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > >> So how about marking commits (using the metainfo-cache facility) that > >> has an ancestor (not necessarily its direct parent) that records a > >> younger timestamp (e.g. 1 is such a commit, as its ancestors include > >> things like 2 and 4)? There should be relatively small number of them, > >> and still_interesting() logic can be told to dig through such commits > >> even if everybody is uninteresting in the active list. > > ... > >> * As to "tag --contains", when timestamp based heuristics breaks down is > >> when a tagged commit incorrectly records way young timestamp or the > >> "want" commit records way old timetsamp. I haven't thought things > >> through, but the same metainfo-cache may be useful to detect which > >> commit to dig through ignoring the cutoff heuristics. > > > > It can also break down if intermediate commits are wrong, because we > > have to traverse backwards, and we may erroneously cutoff early. > > > > For example: > > > > A--B--C > > > > timestamp(A) = 2 > > timestamp(B) = 1 # skewed! > > timestamp(C) = 3 > > > > If tag=C and want=A, then we traverse backwards from C. We can't stop > > immediately because we know that 2 < 3. But we go back to B, and see > > that 2 > 1, and assume that A cannot possibly be an ancestor of B. > > I envisioned that the metainfo-cache to help rev-list I mentioned earlier > would mark B having an ancestor A that has a timestamp younger than it, so > I think we can certainly notice that we have to "dig through" B. Right. I thought you were talking about the case where we did not have such a cache. But given your response, did you mean: If we have such a cache, then the only thing left to worry about is when we specifically ask about a commit (either a tag or a "want" commit) that is skewed. That I agree with. -Peff -- 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