Shawn O. Pearce wrote:
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
$ git rev-list v1.5.0-rc0..master | wc -l
220
$ git rev-list v1.4.4.4..master | wc -l
584
so that's one more case where it got things right.
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?
Sounds sensible. Without doing this, we'd more or less constantly get
bitten by it when pulling a maintenance branch with a (as currently
calculated) more recent tag than the one that actually sits on the
branch we're tagging.
The only case we'd get it wrong is if tags are close to each other,
someone tags a feature-branch before it being merged to master, then
merges it and cuts a release.
In my experience all software projects have a single branch used for
releases, and that's the one that's checked out when the tag is created.
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.
The only problem I foresee is that v1.4.4.4 *looks* closer when viewed
in gitk/qgit, but there it also looks like it's on a different branch,
so we're probably safe from user harrassment there too.
Possibly we'd want to have both, with the old behaviour requiring a
switch to obtain (--date-order ?).
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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