Re: Support customized reordering in version sort

[Junio C Hamano <gitster@pobox.com>]

On Fri, Feb 20, 2015 at 7:33 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>>>
>>> My idea is to make it easy for the user to change the sort algorithm.
>>> And it's probably intuitive to just substitute a string with
>>> something. So if "1-rc1" is put incorrectly before "1.1" and you
>>> realize that "1.999" ought to be the last one before "2". You could
>>> tell git to internally replace "1-rc1" with "1.999".
>>>
>>> This patch does that. The user feeds substitution rules via
>>> versionsort.substitute config keys, e.g.
>>>
>>>     git config versionsort.substitute "-rc .999"
>>
>> I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
>> 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...
>> and then 1.1 (aka 1.1-final).
>>
>> If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
>> it make 1 come after 1.99911, and 1.1.9992 come before 1.1?
>>
>> I didn't read the patch text and perhaps the explanation above is the only
>> thing faulty about your message, or perhaps my reading is faulty and the
>> above describes a sound idea, but I do not see how the above makes sense.
>
> No, faulty thinking. Back to the whiteboard..

One version of vercmp() I read went like this:

 (1) Chomp the version strings into an alternate runs of digits and
non-digits. e.g. 1.2.13 becomes
      "1", ".", "2", "." and "13" while 1.2.9 becomes "1", ".", "2",
"." and "9".
 (2) Compare corresponding elements with strcmp() for runs of
non-digits, and numerically for
      runs of digits. In the above example, up to the shared "1.2."
would compare equal, and the
      final run of digits, "13" and "9" are compared numerically and
we declare that 1.2.13 comes
      later.

I think you can add a twist by introducing "optionally this can
appear" substring. When there is
such an optional substring defined, you also define if the side that
lack the optional substring
comes before or after the side that has one. For example, you declare
"[-]rc" as "optional
substring that makes the owner of such a substring sort before others"
(call it "optional negative
substring") and comparing 2.0-rc12, 2.0-rc2 and 2.0:

 - "2.0" becomes "2", ".", "0" and "2.0-rc2" becomes "2", ".", "0",
"-rc", "2". Comparing them
   from left to right, the first difference is "lack of anything (2.0
side runs out tokens)" and
   "-rc", which is marked as optional negative. Hence 2.0-rc2 sorts before 2.0

 - "2.0-rc12" and "2.0-rc2" splits into tokens similarly. The first
difference you see will be
   after you match "-rc" and "-rc", which is "12" vs "2". Comparing
them numerically, you
   know "2.0-rc12" comes later.

You can define values to optional negatives and optional positives to
express a more
elaborate sort order e.g.

  1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1

even though "-post" does not have to be declared as optional positive.