Re: [PATCH] use natural ordering to display list of branches.

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] use natural ordering to display list of branches.

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:42

"Cedric Vivier" [off-list ref] writes:
On Sat, Jun 7, 2008 at 1:06 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
quoted
On Fri, Jun 6, 2008 at 11:04 PM, Brandon Casey [off-list ref] wrote:
quoted
But can't that be just as easily done by piping through sort? (I
understand there is a platform which lacks the sort utility, boohoo)
Yes, but sort does not have a natural sort option afaik.
sort -n
Hi!

It is not natural sort but usual boring non-natural numeric sort ;)
With the use-case in original post the list would appear exactly the
same than with strcmp sort.
Somebody suggested strvercmp(); how does the natcmp() compare with it?

Re: [PATCH] use natural ordering to display list of branches.

From: Cedric Vivier <hidden>
Date: 2016-06-15 22:44:42

On Sat, Jun 7, 2008 at 2:17 AM, Junio C Hamano [off-list ref] wrote:
Somebody suggested strvercmp(); how does the natcmp() compare with it?
Yeah I did, as a heads-up from the discussion on the apache
mailing-list linked earlier.
I've just checked out glibc's implementation, the result would be the
same, the code seems better to me, and there is no doubt the license
is 100% compatible this way [1], sounds cool.

[1] as I guess we'd still have to borrow the code from glibc and put
it into git's compat/ directory (or whatever name is choosen in the
end for this kind of borrowed stuff) to make it work on non-glibc
platforms (?)

Re: [PATCH] use natural ordering to display list of branches.

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:42

"Cedric Vivier" [off-list ref] writes:
On Sat, Jun 7, 2008 at 2:17 AM, Junio C Hamano [off-list ref] wrote:
quoted
Somebody suggested strvercmp(); how does the natcmp() compare with it?
Yeah I did, as a heads-up from the discussion on the apache
mailing-list linked earlier.
I've just checked out glibc's implementation, the result would be the
same, the code seems better to me, and there is no doubt the license
is 100% compatible this way [1], sounds cool.

[1] as I guess we'd still have to borrow the code from glibc and put
it into git's compat/ directory (or whatever name is choosen in the
end for this kind of borrowed stuff) to make it work on non-glibc
platforms (?)
Yes, and we have precedents to it, like compat/strcasestr.c
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help