On Sun, Sep 13, 2015 at 3:07 AM, Jeff King <peff@xxxxxxxx> wrote: >> The thing is, traversing first-parent chain in reverse fundamentally >> is undefined. You can fork multiple topics at the tip of 'master' >> and each of the topics may be single strand of pearls, but which one >> of the topics is the first-child-chain---there is no answer to that >> question. > > In general I think I agree, but in the case of blame, we know that we > are starting from a single tip (and we know because we are using > first-parent that we remain in a single strand of pearls, because we > follow only one parent and there are no cycles). The thing is that the patch is inside revision.c machinery for --children, and "rev-list --first-parent --children ^A ^B C" (i.e. range with multiple bottoms) may be a perfectly a reasonable request. The requestor does not necessarily know if A or B is an ancestor of C on the first-parent chain. I am not sure if we are introducing unintended consequences on this unrelated request only to change the behaviour of "blame". For that matter, I am not sure how "blame A..B" with first-parent & reverse should behave when A is not an ancestor on the first-parent chain. Wouldn't we try to find a cut-point on the first-parent chain by traversing first-parent chain from B and painting them as positive, while traversing _all_ parents from B and painting them as negative, until the traversal intersect? And wouldn't we discover at least two children (one positive and one negative) for the cut point we discover by that traversal? That cut point would be the (fake) latest state the blame traversal starts at, and then we try to use the first (fake) parent that in real life is the first child (which we do not have a good definition for). And at that point a simple panda brain explodes ;-) We might end up doing the right thing even in that case, but I haven't convinced myself about that (yet). If the change were limited to "blame", the change may be much less problematic. -- 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