From: SZEDER Gábor <szeder@ira.uka.de>
Date: Tue, 06 Sep 2016 19:45:50 GMT
Subject: Re: 2.10.0: multiple versionsort.prereleasesuffix buggy?
Message-ID: <20160906214550.Horde.ducOghtmsQb9pQ6lixxddVz@webmail.informatik.kit.edu>
In-Reply-To: <20160906040739.37otpk3l2wt7qfbb@sigill.intra.peff.net>


Hi,


Quoting Jeff King <peff@peff.net>:

> On Tue, Sep 06, 2016 at 03:07:59AM +0200, SZEDER Gábor wrote:
>
>>> So that seems wrong. Even weirder, if I set _only_ "-beta", I get:
>>>
>>>  $ git tag -l --sort=version:refname | grep -v ^2.6.0
>>>  2.6.0-beta-2
>>>  2.6.0-beta-3
>>>  2.6.0-beta-4
>>>  2.6.0
>>>  2.6.0-RC1
>>>  2.6.0-RC2
>>>  2.6.0-beta-1
>>>
>>> Umm...what? beta-1 is sorted away from its companions? That's weird.
>>>
>>> I wondered if the presence of "-" after the suffix ("beta-1" rather than
>>> "beta1") would matter. It looks like that shouldn't matter, though; it's
>>> purely doing a prefix match on "do these names differ at a prerelease
>>> suffix".
>>>
>>> But something certainly seems wrong.
>>
>> Some of the weirdness is caused by the '-' at the _beginning_ of the
>> suffixes, because versioncmp() gets confused by suffixes starting with
>> the same character(s).
>
> Oh, right, that makes sense. So it's effectively not finding _any_
> suffix between X-RC1 and X-beta-1, because we only start looking after
> "X-", and none of them match.
>
> I am still confused why "2.6.0-beta-1" doesn't get sorted with its
> peers. I'd guess that the comparison function doesn't actually provide a
> strict ordering, so the results depend on the actual sort algorithm, and
> which pairs it ends up comparing.

Turns out that this weirdness is caused by that leading '-' in the suffix,
too.

Here is a manageably small recipe to reproduce:

     $ git -c versionsort.prereleasesuffix=-beta tag -l  
--sort=version:refname v2.1.0* v2.1.{1,2}
     v2.1.0-beta-2
     v2.1.0-beta-3
     v2.1.0
     v2.1.0-RC1
     v2.1.0-RC2
     v2.1.0-beta-1
     v2.1.1
     v2.1.2

Tracing which pairs of tagnames are compared, I found that somewhere along
the line "v2.1.0-beta-1" happens to be compared to "v2.1.0-RC2", and the
issue described in my previous email strikes again: the '-' is part of the
common part of the two tagnames, swap_prereleases() gets only "beta-1" and
"RC2", thus it can't match the configured "-beta" suffix, and since the
byte value of 'b' is higher than that of 'R', "-beta-1" is sorted after
"-RC2".  OTOH, "v2.1.0-beta-2" and "v2.1.0-beta-3" are only compared to
each other or to final release tags, but never to any "-RCx" tags, hence
they are sorted properly.

Once I finish teaching versioncmp() and swap_prereleases() to cope with
leading characters of a prereleaseSuffix being part of the common part of
two tagnames, this out-of-order "beta-1" issue will be gone as well.

Best,
Gábor