Theodore Tso <tytso@xxxxxxx> wrote: > On Mon, Jan 08, 2007 at 12:11:35PM -0800, Junio C Hamano wrote: > > One question is how you would sort the result. If you sort them > > by taggerdate, you would get v1.4.4.4 anyway ;-). > > I was assuming either lexigraphically, or via some really complicated > rpm/dpkg version number comparison scheme. :-) > > > If we go with topology, we do not necessarily have to find all > > the tags. When we hit a commit that is tagged, we can stop the > > traversal (so after finding v1.5.0-rc0, we do not have to go > > back along the 'master' lineage to find v1.4.4 tag). Traversing > > from the tip of 'master' (or 'next') this way we will notice > > that v1.5.0-rc0 and v1.4.4.4 are the candidates without going > > any further in the past. > > > > But the question still remains which one between the two to > > pick. > > Yeah, that is the question. If we're willing to look at the tag name, > it's pretty clear that if both v1.5.0-rc0 and v1.4.4.4 is reachable > from the head, it should be based on the "newer" version, i.e., > v1.5.0-rc0. A human can figure this out easily, but algorithimically > we end up having to use something like the rpm or dpkg version > comparison algorithm, both of which are hueristics that will sometimes > get thigns wrong. $ git rev-list v1.5.0-rc0..next | wc -l 687 $ git rev-list v1.4.4.4..next | wc -l 1051 So what about doing Junio's suggestion of going by topology and coming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4 right now), and if more than one is found compute the number of commits between each tag and the requested revision, and take the tag that has a smallest number of commits? I think it would come up right more often than not and avoids any sort of tag name parsing algorithm. It is also somewhat explainable to users as it does have some common sense: the tag "nearest" to the requested revision is the one that has the most number of commits in common with the requested revision. -- Shawn. - 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