"Luis R. Rodriguez" <mcg...@do-not-panic.com> writes: > I think ultimately this reveals that given that tags *can* be > arbitrary and subjective,...
Yes; see the part at the bottom. >> Commit A can be described in terms of both v3.4 and v9.0, > > And in the real example case, why *would* c5905afb' be be described in > terms of v3.5 instead of v3.4 ? I am not interested in graphing that particular history between v3.4 and v3.5 myself. If you are interested, I already gave you enough information on how to figure that out. >> - find candidate tags that can be used to "describe --contains" >> the commit A, yielding v3.4, v3.5 (not shown), and v9.0; > >> - among the candidate tags, cull the ones that contain another >> candidate tag, rejecting v3.5 (not shown) and v9.0; > >> - among the surviving tags, pick the closest. >> >> Hmm? > > Sounds good to me! Not so fast ;-) My other message to Peff in response to his another example has an updated position on this. "Reject candidates that can reach other candidates" is universally correct, but after that point, there are at least three but probably more options that suit preference of different people and project to break ties: - Your case that started this thread may want to favor v3.4 if only because that v3.4 _sounds_ smaller than v4.0 (in Peff's example), even when v3.4 and v4.0 do not have ancestry relationship. - The "closest" we have had is a heuristic to produce a result that is textually shorter. - And as I alluded to, "which one has the earliest timestamp?", is another valid question to ask. And there may be more to appear. A new command line option (and possibly a new configuration) to choose from these three (and more heuristics that will be added later) would be necessary. -- 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
