From: SZEDER Gábor Date: Wed, 05 Oct 2016 21:26:09 GMT Subject: Re: [PATCH 5/5] versioncmp: cope with common leading parts in versionsort.prereleaseSuffix Message-ID: <20161005232609.Horde.VetzEIKHDJUdcaOod9sHxuK@webmail.informatik.kit.edu> In-Reply-To: Quoting Junio C Hamano : > SZEDER Gábor 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 ;)