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

From: SZEDER Gábor <szeder@ira.uka.de>
Date: Oct 5, 2016, 21:26 UTC
Message-ID: <20161005232609.Horde.VetzEIKHDJUdcaOod9sHxuK@webmail.informatik.kit.edu>
In-Reply-To: <xmqq4m4qrapv.fsf@gitster.mtv.corp.google.com>

Quoting Junio C Hamano <gitster@pobox.com>:

Show 20 quoted lines

> SZEDER Gábor <szeder@ira.uka.de> writes:
>
>> And a final sidenote: sorting based on the longest matching suffix
>> also allows us to (ab)use version sort with prerelease suffixes to
>> sort postrelease tags as we please, too:
>>
>>  $ ~/src/git/git -c versionsort.prereleasesuffix=-alpha \
>>                  -c versionsort.prereleasesuffix=-beta \
>>                  -c versionsort.prereleasesuffix= \
>>                  -c versionsort.prereleasesuffix=-gamma \
>>                  -c versionsort.prereleasesuffix=-delta \
>>                  tag -l --sort=version:refname 'v3.0*'
>>  v3.0-alpha1
>>  v3.0-beta1
>>  v3.0
>>  v3.0-gamma1
>>  v3.0-delta1
>
> Assuming that gamma and delta are meant to indicate "these are
> post-release updates",

Indeed they were meant as post-release suffixes. Naturally following alpha and beta, they were the first to spring to mind that should be sorted in non-lexicographical order, so I could show of postrelease reordering. It's just that we don't have a config like 'versionsort.postreleasesuffix', which is half the abuse. The other half of the abuse is that I had to explicitly indicate the position of suffixless versions with an empty suffix between pre- and postrelease suffixes. The empty suffix matches on every tag, but then it's overridden by all configured suffixes, so such a version just stays in the middle.

> I think a mechanism that can yield the above
> result is fantastic ;-)

Heh.

Gut feeling tells me that I should take this as a subtle encouragement to look into adding 'versionsort.postreleasesuffix', shouldn't I ;)