Jeff King <peff@xxxxxxxx> writes: > On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote: > > >> This one, and $gmane/264101, are a few instances of this known issue >> raised here recently. > > If $gmane/264101 is caused by clock skew, I'd find that disturbing. > Those algorithms are supposed to be "correct, but slower" in the face of > skew, not ever incorrect. My understanding is that the commit painting done by merge-base is designed to be always correct, but the A..B revision traversal depends on SLOP being big enough. When the traversal queue is filled with all UNINTERESTING commits, some of which needs to be dug to reveal newer commits that are not yet painted as UNINTERESTING in order to get the complete picture, the still_interesting() logic will end up stopping prematurely, leaving commits that are actually UNINTERESTING in the topological sense unpainted in the resulting newlist that is assigned to revs->commits in limit_list(), yielding an incorrect result. >> > Calculating them is simple. Caching and storage is the bigger question. >> >> Yes, also having to handle the ones whose generation numbers haven't >> been computed yet adds to the complexity. > > I'm not sure it's that bad. If you cache generation numbers for all > known commits when you repack, then worst case you have to traverse all > commits not in the pack. > ... > IMHO, if you are going to go to the trouble to detect and store skew, > you should just go to the trouble to calculate and store reliable > generation numbers. I would actually prefer a solution with generation numbers, of course, because that would give us provably correct result. If it can be done without too much hassle, I am all for it. Scrap the half-baked "I've been wondering" compromise ;-) Thanks. -- 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