On Tue, Dec 20, 2016 at 09:50:42AM +0100, SZEDER Gábor wrote:
> > It just seems like the whole thing would conceptually easier if we
> > pre-parsed the versions into a sequence of elements, then the comparison
> > between any two elements would just walk that sequence. The benefit
> > there is
On Wed, Dec 14, 2016 at 6:08 PM, Jeff King wrote:
> On Thu, Dec 08, 2016 at 03:23:54PM +0100, SZEDER Gábor wrote:
>
>> > With my patches it looks like this:
>> >
>> > $ git -c versionsort.prereleasesuffix=-pre \
>> > -c versionsort.prereleasesuffix=-prerelease \
>> >
Jeff King writes:
> On Thu, Dec 08, 2016 at 03:23:54PM +0100, SZEDER Gábor wrote:
>
>> > With my patches it looks like this:
>> >
>> > $ git -c versionsort.prereleasesuffix=-pre \
>> > -c versionsort.prereleasesuffix=-prerelease \
>> > tag -l
On Thu, Dec 08, 2016 at 03:23:54PM +0100, SZEDER Gábor wrote:
> > With my patches it looks like this:
> >
> > $ git -c versionsort.prereleasesuffix=-pre \
> > -c versionsort.prereleasesuffix=-prerelease \
> > tag -l --sort=version:refname
> > v1.0.0-prerelease1
> >
> After having slept on this a couple of times
After having slept on it a few (erm...) more times...
> I think the longest
> matching prerelease suffix should determine the sorting order.
>
> A release tag usually consists of an optional prefix, e.g. 'v' or
> 'snapshot-', followed by the actual
5 matches
Mail list logo