Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> I wonder if you can >> define the weight as a recursive function of the parents. > > I do not think we can. A merge Z between X (that has N commits > behind it) and Y (that has M commits behind it) has at most N+M+1 > commits behind it (counting itself), but we cannot tell how many > among these N and M are shared. You can theoretically take all the merge bases between X and Y, magically come up with the "weight" of a fictitious merge across these merge bases, and subtract that number from N+M to arrive at the weight of Z, I suppose, but it is not clear what an efficient implementation of that "magically" part looks like. I think that is where we stopped when we tried to optimize the "rev-list --bisect" node weighting logic; it punts handling the merges, and only optimizes single strand of pearls on top of a merge with a known weight. -- 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