I just pulled and built 'next'...

I just pulled and built 'next'...

[Theodore Ts'o]

I just pulled and built 'next' and it reported a version number of
1.4.4.4.g71bb6 -- and not one v1.5.0-rc0.g71bb6.  I can understand why,
since it found the changes pulled in from the maint branch before it
found the v1.5.0-rc0 tag --- but it could be more than a little
misleading.  Is this something that can be fixed in any way, short of
finding all of the tags reachable from HEAD and then doing a sort?  That
seems like a gross kludge, but I can't think of any other way of fixing
it.

						- Ted

Re: I just pulled and built 'next'...

[Junio C Hamano]

"Theodore Ts'o" <tytso@mit.edu> writes:

> I just pulled and built 'next' and it reported a version number of
> 1.4.4.4.g71bb6 -- and not one v1.5.0-rc0.g71bb6.  I can understand why,
> since it found the changes pulled in from the maint branch before it
> found the v1.5.0-rc0 tag --- but it could be more than a little
> misleading.  Is this something that can be fixed in any way, short of
> finding all of the tags reachable from HEAD and then doing a sort?  That
> seems like a gross kludge, but I can't think of any other way of fixing
> it.

One question is how you would sort the result.  If you sort them
by taggerdate, you would get v1.4.4.4 anyway ;-).

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.

Re: I just pulled and built 'next'...

[Theodore Tso]

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.

						- Ted

Re: I just pulled and built 'next'...

[Shawn O. Pearce]

Theodore Tso <tytso@mit.edu> 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.

Re: I just pulled and built 'next'...

[Andreas Ericsson]

Shawn O. Pearce wrote:
> Theodore Tso <tytso@mit.edu> 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@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: I just pulled and built 'next'...

[Theodore Tso]

On Mon, Jan 08, 2007 at 10:21:24PM -0500, Shawn O. Pearce wrote:
> 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?

Ah, thanks for showing the example using git-rev-list.  I was assuming
"topology" based on the distance as shown by gitk, and that's quite
different from what git-rev-list shows.  Agreed, that hueristic makes
a lot of sense.

						- Ted

Re: I just pulled and built 'next'...

[Uwe Kleine-König]

Hello,

Shawn O. Pearce wrote:
>   $ 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?
One scenario where this will fail is when a bugfix is commited on top of
v1.4.4.4 and then is merged into v1.5.0-rc0+gabcdef.

Just my 0.02$.

Uwe

-- 
Uwe Kleine-König

exit vi, lesson III:
: x ! <CR>

NB: may write current file

Re: I just pulled and built 'next'...

[Shawn O. Pearce]

Uwe Kleine-K?nig <zeisberg@informatik.uni-freiburg.de> wrote:
> Shawn O. Pearce wrote:
> >   $ 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?
>
> One scenario where this will fail is when a bugfix is commited on top of
> v1.4.4.4 and then is merged into v1.5.0-rc0+gabcdef.

Actually it still works, and does what you want.  The scenario you
are describing is exactly the one that caused this bug to appear,
and is the one my suggestion is trying to offer a partly sane
solution to.

Try it.  Checkout v1.4.4.4, make a trivial commit, merge it to
master, then merge that to next.  You'll still come up with the fact
that master (or next) have less commits different from v1.5.0-rc0
than they have from your hypothetical v1.4.4.5.  In this case the
the v1.5.0-rc0 tag should still be taken.

Its easy to explain this difference in terms of what the user
sees via `git log` and `git rev-list`.  We're taking the tag which
has the fewest commits different.  This will hold even if `next`
suddenly gets another 800 new commits (changing the above counts
to 1847 and 1851 respectively).


Where it might fail is if v1.4.4.5 suddenly gets another 1000 commits
as part of its bug fix release and those all get merged into next.
Now v1.4.4.5 is closer than v1.5.0-rc0.  But you know what, that
does still make a lot of sense.  If you look at the git log (or
git shortlog) between v1.4.4.5 and next there's less output than
if you look at it between v1.5.0-rc0 and next.

-- 
Shawn.

Re: I just pulled and built 'next'...

[Uwe Kleine-Koenig]

Hello,

Shawn O. Pearce wrote:
> Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de> wrote:
> > Shawn O. Pearce wrote:
> > >   $ 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?
> >
> > One scenario where this will fail is when a bugfix is commited on top of
> > v1.4.4.4 and then is merged into v1.5.0-rc0+gabcdef.
> 
> Actually it still works, and does what you want.  The scenario you
> are describing is exactly the one that caused this bug to appear,
> and is the one my suggestion is trying to offer a partly sane
> solution to.
OK, I got it.  I thought in "shortest ways", but that's obviously
different from "commits inbetween".  Thanks for that one more
explanation.  Now it really makes sense to me.

Best regards
Uwe
-- 
Uwe Kleine-Koenig

http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2