Subject: Re: for-each-ref output order change in 2.7.0

From: Johannes Sixt <[email-masked]>
Date: Sun, 10 Jan 2016 10:51:52 +0100

Am 09.01.2016 um 22:29 schrieb Karthik Nayak:
> On Sat, Jan 9, 2016 at 11:30 PM, Johannes Sixt <[email-masked]> wrote:
>> Am 09.01.2016 um 18:21 schrieb Karthik Nayak:
>>>>>
>>>>> (Note: The alphabetical-ness of the branch names is reversed, which
>>>>> seems logical given my original sort was -committerdate. A
>>>>> --sort=refname looks like this.

After reading up on branch sorting, I notice that the single dash in 
front of committerdate is not a typo, but a request to sort in reverse. 
Therefore, the resulting sort order, which was

refs/heads/!@#% -> Tue Jan 3 17:04:06 2012 +1100
refs/heads/@#% -> Tue Jan 3 17:00:51 2012 +1100
refs/heads/@#$% -> Tue Jan 3 17:00:51 2012 +1100
refs/heads/% -> Tue Jan 3 17:00:51 2012 +1100
refs/heads/!@#$% -> Tue Jan 3 17:00:51 2012 +1100

is totally correct.

>>>>>
>>>>> refs/heads/!@#$% -> Tue Jan 3 17:00:51 2012 +1100
>>>>> refs/heads/!@#% -> Tue Jan 3 17:04:06 2012 +1100
>>>>> refs/heads/% -> Tue Jan 3 17:00:51 2012 +1100
>>>>> refs/heads/@#$% - >Tue Jan 3 17:00:51 2012 +1100
>>>>> refs/heads/@#% -> Tue Jan 3 17:00:51 2012 +1100
>>>>>
>>>>> That's probably more correct too.)

But I don't know what would be "more" correct here. It's simply correct.

>>> This is correct as per the patch, But I'm wondering if this is desired.
>>> I.E when sorting in reverse order should the fallback (alphabetical sort)
>>> also be in reverse order?
>>
>>
>> IMO, the fallback sorting should be in reverse order only when the user
>> explicitley asked for reverse order. Just because committer date implies
>> some "reverse" ordering should not imply that refs with the same committer
>> date should also be listed in reverse alphabetical order.

I was wrong here. Sorting by committerdate does not imply reverse-ness. 
I just did not know enough about the --sort options when I wrote this 
paragraph.

>
> I was thinking along the same lines. But do we want to expose the fallback to
> the user (i.e let them choose if its reversible or not)?

No, we do not want to expose the fallback to the user. And as far as I 
can see, no further change is required.

-- Hannes