Am 09.01.2016 um 22:29 schrieb Karthik Nayak:
On Sat, Jan 9, 2016 at 11:30 PM, Johannes Sixt <j6t@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html