From: Johannes Sixt Date: Sun, 10 Jan 2016 09:51:52 GMT Subject: Re: for-each-ref output order change in 2.7.0 Message-ID: <569229B8.9000009@kdbg.org> In-Reply-To: Am 09.01.2016 um 22:29 schrieb Karthik Nayak: > On Sat, Jan 9, 2016 at 11:30 PM, Johannes Sixt 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