Thread (6 messages) flat view 6 messages, 4 authors, 2016-06-15

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

From: Johannes Sixt <hidden>
Date: 2016-06-15 23:07:40

Am 09.01.2016 um 22:29 schrieb Karthik Nayak:
On Sat, Jan 9, 2016 at 11:30 PM, Johannes Sixt [off-list ref] wrote:
quoted
Am 09.01.2016 um 18:21 schrieb Karthik Nayak:
quoted
quoted
quoted
(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.
quoted
quoted
quoted
quoted
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.
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help