Re: [PATCH 5/5] versioncmp: cope with common leading parts in versionsort.prereleaseSuffix

From: SZEDER Gábor <szeder@ira.uka.de>
Date: Sep 7, 2016, 15:48 UTC
Message-ID: <20160907174841.Horde.Ru1LBEeLKomznlWVG-ZnS-Q@webmail.informatik.kit.edu>
In-Reply-To: <20160907151251.30978-6-szeder@ira.uka.de>

Quoting SZEDER Gábor <szeder@ira.uka.de>:

Show 28 quoted lines

> Version sort with prerelease reordering sometimes puts tagnames in the
> wrong order, when the common part of two compared tagnames ends with
> the leading character(s) of one or more configured prerelease
> suffixes.
>
>   $ git config --get-all versionsort.prereleaseSuffix
>   -beta
>   $ git tag -l --sort=version:refname v2.1.*
>   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
>
> The reason is that when comparing a pair of tagnames, first
> versioncmp() looks for the first different character in a pair of
> tagnames, and then the swap_prereleases() helper function checks for
> prerelease suffixes _starting at_ that character.  Thus, when in the
> above example the sorting algorithm happens to compare the tagnames
> "v2.1.0-beta-1" and "v2.1.0-RC2", swap_prereleases() will try to match
> the suffix "-beta" against "beta-1" to no avail, and the two tagnames
> erroneously end up being ordered lexicographically.
>
> To fix this issue change swap_prereleases() to look for configured
> prerelease suffixes containing that first different character.

Now, while I believe this is the right thing to do to fix this bug, there is a corner case, where multiple configured prerelease suffixes might match the same tagname:

   $ git config --get-all versionsort.prereleaseSuffix
   -bar
   -baz
   -foo-bar
   $ ~/src/git/git tag -l --sort=version:refname
   v1.0-foo-bar
   v1.0-foo-baz

I.e. when comparing these two tags, both "-bar" and "-foo-bar" would match "v1.0-foo-bar", and as "-bar" comes first in the config file, it wins, and "v1.0-foo-bar" is ordered first. An argument could be made to prefer longer matches, in which case "v1.0-foo-bar" would be ordered according to "-foo-bar", i.e. as second. However, I don't know what that argument could be, to me neither behavior is better than the other, but the implementation of the "longest match counts" would certainly be more complicated.

The argument I would make is that this is a pathological corner case that doesn't worth worrying about.

Best, Gábor