Junio C Hamano <gits...@pobox.com> writes:
> Jeff King <p...@peff.net> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html