On Wed, Sep 7, 2016 at 10:48 PM, SZEDER Gábor <szeder@xxxxxxxxxx> wrote: > 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. Maybe we should keep a note about this in config.txt? If it's not worth bothering/scaring the users about, I suggest you keep this in the commit message. -- Duy