Jeff King <peff@xxxxxxxx> writes: > ---A---B---C-----D---E---F (maint, v3.4) > \ \ / > \ ---G-----H---I (master, v4.0) > \ / / > ------J--- > > The fix is J, and it got merged up to maint at D, and to master at H. > v4.0 does not contain v3.4. What's the best description of J? > > By the rules above, we hit the third rule "pick the closest". Which > means we choose v3.4 or v4.0 based solely on how many commits are > between the topic's merge and the tag release. Which has nothing at all > to do with the topic itself. Even if J..F and J..I were of the same hop-count, there is no fundamental reason to choose one over the other. What is "best" at that point depends on what the user wants to see. - Luis's case that started this thread may want to favor v3.4 if only because that "sounds" the smaller, even though v3.4 and v4.0 in the illustration cannot be compared. - I think the "closest" we have had is primarily a heuristic to favour the result that is textually shorter. - And as I alluded to, "which one has the earliest timestamp?", is another valid question to ask. In other words, there is no single "correct" answer, once you have multiple canidates that are all valid from topological point of view. > In this case we'd show v4.0 (because "J-H-I" is shorter than "J-D-E-F"). > But I suspect most users would want to know v3.4, because they want to > know the "oldest" release they can move up to that contains the commit. > But that notion of oldness is not conveyed by the graph above; it's only > an artifact of the tag names. Yes, exactly. -- 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