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

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

[Cedric Vivier]

Hi everyone,

This small patch makes git display list of branches in natural order.
This way, when you name your branches against, for instance, a bug number from
some bug-tracking tool, the list will show up in a natural/human/logical order.

Current behavior for "git branch":
BUG-1040-doing-bar-is-too-slow
BUG-84-calling-Z-with-null-segfaults
BUG-900-program-freezes-when-user-click-on-button
experimental-feature-X
master

With the patch:
BUG-84-calling-Z-with-null-segfaults
BUG-900-program-freezes-when-user-click-on-button
BUG-1040-doing-bar-takes-too-much-time
experimental-feature-X
master


Signed-off-by: Cedric Vivier <cedricv@neonux.com>
---
 Makefile         |    3 +
 builtin-branch.c |    3 +-
 strnatcmp.c      |  179 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 strnatcmp.h      |   32 ++++++++++
 4 files changed, 216 insertions(+), 1 deletions(-)
 create mode 100644 strnatcmp.c
 create mode 100644 strnatcmp.h

diff --git a/Makefile b/Makefile
index cce5a6e..469b312 100644
--- a/Makefile
+++ b/Makefile
@@ -376,6 +376,7 @@ LIB_H += tree-walk.h
 LIB_H += unpack-trees.h
 LIB_H += utf8.h
 LIB_H += wt-status.h
+LIB_H += strnatcmp.h

 LIB_OBJS += alias.o
 LIB_OBJS += alloc.o
@@ -471,6 +472,7 @@ LIB_OBJS += write_or_die.o
 LIB_OBJS += ws.o
 LIB_OBJS += wt-status.o
 LIB_OBJS += xdiff-interface.o
+LIB_OBJS += strnatcmp.o

 BUILTIN_OBJS += builtin-add.o
 BUILTIN_OBJS += builtin-annotate.o
@@ -1141,6 +1143,7 @@ $(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h
xdiff/xdiff.h xdiff/xtypes.h \
 $(XDIFF_LIB): $(XDIFF_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(XDIFF_OBJS)

+strnatcmp.o: strnatcmp.c

 doc:
 	$(MAKE) -C Documentation all
diff --git a/builtin-branch.c b/builtin-branch.c
index d279702..c9c6788 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -13,6 +13,7 @@
 #include "remote.h"
 #include "parse-options.h"
 #include "branch.h"
+#include "strnatcmp.h"

 static const char * const builtin_branch_usage[] = {
 	"git-branch [options] [-r | -a] [--merged | --no-merged]",
@@ -279,7 +280,7 @@ static int ref_cmp(const void *r1, const void *r2)

 	if (c1->kind != c2->kind)
 		return c1->kind - c2->kind;
-	return strcmp(c1->name, c2->name);
+	return strnatcmp(c1->name, c2->name);
 }

 static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
diff --git a/strnatcmp.c b/strnatcmp.c
new file mode 100644
index 0000000..46bae0f
--- /dev/null
+++ b/strnatcmp.c
@@ -0,0 +1,179 @@
+/* -*- mode: c; c-file-style: "k&r" -*-
+
+  strnatcmp.c -- Perform 'natural order' comparisons of strings in C.
+  Copyright (C) 2000, 2004 by Martin Pool <mbp sourcefrog net>
+
+  This software is provided 'as-is', without any express or implied
+  warranty.  In no event will the authors be held liable for any damages
+  arising from the use of this software.
+
+  Permission is granted to anyone to use this software for any purpose,
+  including commercial applications, and to alter it and redistribute it
+  freely, subject to the following restrictions:
+
+  1. The origin of this software must not be misrepresented; you must not
+     claim that you wrote the original software. If you use this software
+     in a product, an acknowledgment in the product documentation would be
+     appreciated but is not required.
+  2. Altered source versions must be plainly marked as such, and must not be
+     misrepresented as being the original software.
+  3. This notice may not be removed or altered from any source distribution.
+*/
+
+
+/* partial change history:
+ *
+ * 2004-10-10 mbp: Lift out character type dependencies into macros.
+ *
+ * Eric Sosman pointed out that ctype functions take a parameter whose
+ * value must be that of an unsigned int, even on platforms that have
+ * negative chars in their default char type.
+ */
+
+#include <ctype.h>
+#include <string.h>
+#include <assert.h>
+#include <stdio.h>
+
+#include "strnatcmp.h"
+
+
+/* These are defined as macros to make it easier to adapt this code to
+ * different characters types or comparison functions. */
+static inline int
+nat_isdigit(nat_char a)
+{
+     return isdigit((unsigned char) a);
+}
+
+
+static inline int
+nat_isspace(nat_char a)
+{
+     return isspace((unsigned char) a);
+}
+
+
+static inline nat_char
+nat_toupper(nat_char a)
+{
+     return toupper((unsigned char) a);
+}
+
+
+
+static int
+compare_right(nat_char const *a, nat_char const *b)
+{
+     int bias = 0;
+
+     /* The longest run of digits wins.  That aside, the greatest
+	value wins, but we can't know that it will until we've scanned
+	both numbers to know that they have the same magnitude, so we
+	remember it in BIAS. */
+     for (;; a++, b++) {
+	  if (!nat_isdigit(*a)  &&  !nat_isdigit(*b))
+	       return bias;
+	  else if (!nat_isdigit(*a))
+	       return -1;
+	  else if (!nat_isdigit(*b))
+	       return +1;
+	  else if (*a < *b) {
+	       if (!bias)
+		    bias = -1;
+	  } else if (*a > *b) {
+	       if (!bias)
+		    bias = +1;
+	  } else if (!*a  &&  !*b)
+	       return bias;
+     }
+
+     return 0;
+}
+
+
+static int
+compare_left(nat_char const *a, nat_char const *b)
+{
+     /* Compare two left-aligned numbers: the first to have a
+     different value wins. */
+     for (;; a++, b++) {
+	  if (!nat_isdigit(*a)  &&  !nat_isdigit(*b))
+	       return 0;
+	  else if (!nat_isdigit(*a))
+	       return -1;
+	  else if (!nat_isdigit(*b))
+	       return +1;
+	  else if (*a < *b)
+	       return -1;
+	  else if (*a > *b)
+	       return +1;
+     }
+
+     return 0;
+}
+
+
+static int strnatcmp0(nat_char const *a, nat_char const *b, int fold_case)
+{
+     int ai, bi;
+     nat_char ca, cb;
+     int fractional, result;
+
+     assert(a && b);
+     ai = bi = 0;
+     while (1) {
+	  ca = a[ai]; cb = b[bi];
+
+	  /* skip over leading spaces or zeros */
+	  while (nat_isspace(ca))
+	       ca = a[++ai];
+
+	  while (nat_isspace(cb))
+	       cb = b[++bi];
+
+	  /* process run of digits */
+	  if (nat_isdigit(ca)  &&  nat_isdigit(cb)) {
+	       fractional = (ca == '0' || cb == '0');
+
+	       if (fractional) {
+		    if ((result = compare_left(a+ai, b+bi)) != 0)
+			 return result;
+	       } else {
+		    if ((result = compare_right(a+ai, b+bi)) != 0)
+			 return result;
+	       }
+	  }
+
+	  if (!ca && !cb) {
+	       /* The strings compare the same.  Perhaps the caller
+	       will want to call strcmp to break the tie. */
+	       return 0;
+	  }
+
+	  if (fold_case) {
+	       ca = nat_toupper(ca);
+	       cb = nat_toupper(cb);
+	  }
+
+	  if (ca < cb)
+	       return -1;
+	  else if (ca > cb)
+	       return +1;
+
+	  ++ai; ++bi;
+     }
+}
+
+
+
+int strnatcmp(nat_char const *a, nat_char const *b) {
+     return strnatcmp0(a, b, 0);
+}
+
+
+/* Compare, recognizing numeric string and ignoring case. */
+int strnatcasecmp(nat_char const *a, nat_char const *b) {
+     return strnatcmp0(a, b, 1);
+}
+
diff --git a/strnatcmp.h b/strnatcmp.h
new file mode 100644
index 0000000..7b2ca39
--- /dev/null
+++ b/strnatcmp.h
@@ -0,0 +1,32 @@
+/* -*- mode: c; c-file-style: "k&r" -*-
+
+  strnatcmp.c -- Perform 'natural order' comparisons of strings in C.
+  Copyright (C) 2000, 2004 by Martin Pool <mbp sourcefrog net>
+
+  This software is provided 'as-is', without any express or implied
+  warranty.  In no event will the authors be held liable for any damages
+  arising from the use of this software.
+
+  Permission is granted to anyone to use this software for any purpose,
+  including commercial applications, and to alter it and redistribute it
+  freely, subject to the following restrictions:
+
+  1. The origin of this software must not be misrepresented; you must not
+     claim that you wrote the original software. If you use this software
+     in a product, an acknowledgment in the product documentation would be
+     appreciated but is not required.
+  2. Altered source versions must be plainly marked as such, and must not be
+     misrepresented as being the original software.
+  3. This notice may not be removed or altered from any source distribution.
+*/
+
+
+/* CUSTOMIZATION SECTION
+ *
+ * You can change this typedef, but must then also change the inline
+ * functions in strnatcmp.c */
+typedef char nat_char;
+
+int strnatcmp(nat_char const *a, nat_char const *b);
+int strnatcasecmp(nat_char const *a, nat_char const *b);
+
-- 
1.5.6.rc1.12.g7f71.dirty

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

[Johannes Schindelin]

Hi,

On Thu, 5 Jun 2008, Cedric Vivier wrote:

> Hi everyone,
> 
> This small patch makes git display list of branches in natural order.
> This way, when you name your branches against, for instance, a bug number from
> some bug-tracking tool, the list will show up in a natural/human/logical order.
> 
> Current behavior for "git branch":
> BUG-1040-doing-bar-is-too-slow
> BUG-84-calling-Z-with-null-segfaults
> BUG-900-program-freezes-when-user-click-on-button
> experimental-feature-X
> master
> 
> With the patch:
> BUG-84-calling-Z-with-null-segfaults
> BUG-900-program-freezes-when-user-click-on-button
> BUG-1040-doing-bar-takes-too-much-time
> experimental-feature-X
> master
> 
> 
> Signed-off-by: Cedric Vivier <cedricv@neonux.com>
> ---

This is not a good commit message.

> @@ -279,7 +280,7 @@ static int ref_cmp(const void *r1, const void *r2)
> 
>  	if (c1->kind != c2->kind)
>  		return c1->kind - c2->kind;
> -	return strcmp(c1->name, c2->name);
> +	return strnatcmp(c1->name, c2->name);
>  }
> 
>  static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,

What about people preferring the status quo?  I think a command line 
option would be in order.

Also, you _might_ want to provide a test case, so that it does not get 
broken by accident.

Other than that: nice.

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Thu, 5 Jun 2008, Cedric Vivier wrote:
>
>> Hi everyone,
>> 
>> This small patch makes git display list of branches in natural order.
>> This way, when you name your branches against, for instance, a bug number from
>> some bug-tracking tool, the list will show up in a natural/human/logical order.
>> 
>> Current behavior for "git branch":
>> BUG-1040-doing-bar-is-too-slow
>> BUG-84-calling-Z-with-null-segfaults
>> BUG-900-program-freezes-when-user-click-on-button
>> experimental-feature-X
>> master
>> 
>> With the patch:
>> BUG-84-calling-Z-with-null-segfaults
>> BUG-900-program-freezes-when-user-click-on-button
>> BUG-1040-doing-bar-takes-too-much-time
>> experimental-feature-X
>> master
>> 
>> 
>> Signed-off-by: Cedric Vivier <cedricv@neonux.com>
>> ---
>
> This is not a good commit message.
>
>> @@ -279,7 +280,7 @@ static int ref_cmp(const void *r1, const void *r2)
>> 
>>  	if (c1->kind != c2->kind)
>>  		return c1->kind - c2->kind;
>> -	return strcmp(c1->name, c2->name);
>> +	return strnatcmp(c1->name, c2->name);
>>  }
>> 
>>  static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
>
> What about people preferring the status quo?  I think a command line 
> option would be in order.
>
> Also, you _might_ want to provide a test case, so that it does not get 
> broken by accident.
>
> Other than that: nice.

Perhaps, as long as we somehow mark clearly the new files added with this
patch as "borrowed code" and not part of git proper, so that people do not
imitate tons of style issues these files have (header inclusion, Emacs
style -*- mode -*- line at the top, useless typedef of nat_char, macros
whose sole purpose to cast arguments given toupper() to (unsigned char),
"partial change history" in comments, short function definition header
split across two lines, multi-line comments).

What the big license notice comment at the top says sounded Ok to me as
well.

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

[Johannes Schindelin]

Hi,

On Thu, 5 Jun 2008, Junio C Hamano wrote:

> Perhaps, as long as we somehow mark clearly the new files added with this
> patch as "borrowed code" and not part of git proper, so that people do not
> imitate tons of style issues these files have.

Right.  Maybe compat/?

Ciao,
Dscho

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

[Cedric Vivier]

On Thu, Jun 5, 2008 at 8:47 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> What about people preferring the status quo?  I think a command line
> option would be in order.

Is there really people preferring the status quo ? ;)
Of course we probably need some debate about making it default or not
but you're completely right there should be an option about that - and
maybe a config variable as well?
How about --sort=ascending|descending|natural (with branch.sort as the
corresponding config var) ?


> Also, you _might_ want to provide a test case, so that it does not get
> broken by accident.

Okay.


> Other than that: nice.

Thanks,


Junio, about the borrowed code, indeed I was not sure where to put it,
initialliy I thought using directory strnatcmp/ like it's done for
mozilla-sha1/ and xdiff/, but well... probably a more general
directory that will be used for other 'borrowed' stuff in the future
makes sense.


Regards,

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

[Marius Storm-Olsen]

Cedric Vivier said the following on 05.06.2008 22:08:
> On Thu, Jun 5, 2008 at 8:47 PM, Johannes Schindelin 
> <Johannes.Schindelin@gmx.de> wrote:
>> What about people preferring the status quo?  I think a command
>> line option would be in order.
> 
> Is there really people preferring the status quo ? ;) Of course we
> probably need some debate about making it default or not but you're
> completely right there should be an option about that - and maybe a
> config variable as well? How about
> --sort=ascending|descending|natural (with branch.sort as the 
> corresponding config var) ?

IMO, we now need to step back, and start considering the ever 
expanding complexity of all the Git command line options. Is there 
_really_ a need for a command line option to control this? Will people 
_really_, for that _one_ invocation change the order of file listing? 
Or, will they simply prefer one particular order, set it, and forget it?

We really need to analyze the use-cases, and do everything we can to 
avoid confusing clutter.

IMO this feature falls into the "configuration-variable, but not 
command-line option" category. (People who _really_ want a different 
order, for that _one_ invocation, are most probable also in the group 
that can write their own little 3-line script to do this.)

Just my 10NOK..

--
.marius

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

[Mike Ralphson]

2008/6/5 Cedric Vivier <cedricv@neonux.com>:
>
> This small patch makes git display list of branches in natural order.
> This way, when you name your branches against, for instance, a bug number from
> some bug-tracking tool, the list will show up in a natural/human/logical order.

[Included as part of patch:]

> +
> +  strnatcmp.c -- Perform 'natural order' comparisons of strings in C.
> +  Copyright (C) 2000, 2004 by Martin Pool <mbp sourcefrog net>
> +
> +  This software is provided 'as-is', without any express or implied
> +  warranty.  In no event will the authors be held liable for any damages
> +  arising from the use of this software.
> +
> +  Permission is granted to anyone to use this software for any purpose,
> +  including commercial applications, and to alter it and redistribute it
> +  freely, subject to the following restrictions:
> +
> +  1. The origin of this software must not be misrepresented; you must not
> +     claim that you wrote the original software. If you use this software
> +     in a product, an acknowledgment in the product documentation would be
> +     appreciated but is not required.
> +  2. Altered source versions must be plainly marked as such, and must not be
> +     misrepresented as being the original software.
> +  3. This notice may not be removed or altered from any source distribution.

2008/6/5 Junio C Hamano <gitster@pobox.com>:
> Perhaps, as long as we somehow mark clearly the new files added with this
> patch as "borrowed code" and not part of git proper...
>...
>
> What the big license notice comment at the top says sounded Ok to me as
> well.

IANAL, but I'm not 100% sure clauses 2a or 3 are strictly GPL
compatible (especially as "altered from" is unlikely to be interpreted
in only one way).

Perhaps we can ask the original author (cc'd) if he is prepared to
license it under GPL2?

I also think the license policy for inclusion in git should be spelt
out in the documentation, i.e. GPL (2+), GPL2 only, GPL2 compatible
etc. SubmittingPatches touches on this area, but only in terms of the
DCoO.  README merely states "Git is an Open Source project covered by
the GNU General Public License."

Some c files state GPL v2 only, others v2 with the "any later version" wording.

I had the same issue when the replacement qsort() implementations came up.

As to the patch, I like the intent, but for consistency should it not
also apply to tags?

Mike

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

[Cedric Vivier]

On Fri, Jun 6, 2008 at 10:42 AM, Mike Ralphson <mike.ralphson@gmail.com> wrote:
> 2008/6/5 Cedric Vivier <cedricv@neonux.com>:
>> +  strnatcmp.c -- Perform 'natural order' comparisons of strings in C.
>> +  Copyright (C) 2000, 2004 by Martin Pool <mbp sourcefrog net>
>
> IANAL, but I'm not 100% sure clauses 2a or 3 are strictly GPL
> compatible (especially as "altered from" is unlikely to be interpreted
> in only one way).
>
> Perhaps we can ask the original author (cc'd) if he is prepared to
> license it under GPL2?
>

I've found a discussion on the Apache mailing-list where the author,
Martin Pool seems to ack that this is ok to include his code in GPL'ed
code or even to relicense it :
http://lists.debian.org/debian-glibc/2003/10/msg00016.html

Also maybe we could use glibc's strverscmp instead, but am not sure of
its portability ?

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

[Mike Ralphson]

2008/6/6 Cedric Vivier <cedricv@neonux.com>:
> On Fri, Jun 6, 2008 at 10:42 AM, Mike Ralphson <mike.ralphson@gmail.com> wrote:
>> 2008/6/5 Cedric Vivier <cedricv@neonux.com>:
>>> +  strnatcmp.c -- Perform 'natural order' comparisons of strings in C.
>>> +  Copyright (C) 2000, 2004 by Martin Pool <mbp sourcefrog net>
>>
>> IANAL, but I'm not 100% sure clauses 2a or 3 are strictly GPL
>> compatible (especially as "altered from" is unlikely to be interpreted
>> in only one way).
>>
>> Perhaps we can ask the original author (cc'd) if he is prepared to
>> license it under GPL2?
>>
>
> I've found a discussion on the Apache mailing-list where the author,
> Martin Pool seems to ack that this is ok to include his code in GPL'ed
> code or even to relicense it :
> http://lists.debian.org/debian-glibc/2003/10/msg00016.html
>
> Also maybe we could use glibc's strverscmp instead, but am not sure of
> its portability ?

Ah ok, I didn't recognise the zlib license. A quick google suggests it
is GPL compatible. Sorry for the noise.

Mike

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

[Paolo Bonzini]

> What about people preferring the status quo?  I think a command line 
> option would be in order.'

config option seems more useful.

Paolo

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

[Johannes Schindelin]

Hi,

On Fri, 6 Jun 2008, Paolo Bonzini wrote:

> > What about people preferring the status quo?  I think a command line 
> > option would be in order.'
> 
> config option seems more useful.

Except, of course, if you have a script that wants to override whatever 
the user set in her config.

Hth,
Dscho

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

[Sverre Rabbelier]

On Fri, Jun 6, 2008 at 8:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Except, of course, if you have a script that wants to override whatever
> the user set in her config.

I think this is why stuff like GDB has both a CLI and a MI. In order
to keep the CLI clean you have to make choices, similar to how we
already separate plumbing from porcelain. I guess in that sense our MI
is the plumbing, and the porcelain is our CLI. Of course, in that case
there needn't be such an option in the porcelain, as long as there is
one in the plumbing ;).
Conclusion, go for the config option but make sure there's a switch
for scripts in the plumbing?

-- 
Cheers,

Sverre Rabbelier

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

[Paolo Bonzini]

Sverre Rabbelier wrote:
> On Fri, Jun 6, 2008 at 8:11 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Except, of course, if you have a script that wants to override whatever
>> the user set in her config.
> 
> I think this is why stuff like GDB has both a CLI and a MI. In order
> to keep the CLI clean you have to make choices, similar to how we
> already separate plumbing from porcelain. I guess in that sense our MI
> is the plumbing, and the porcelain is our CLI. Of course, in that case
> there needn't be such an option in the porcelain, as long as there is
> one in the plumbing ;).
> Conclusion, go for the config option but make sure there's a switch
> for scripts in the plumbing?

Or do the natural sorting only in the porcelain, even if that means 
sorting twice, and use a config option in the porcelain?

(Now, "git branch" is porcelain isn't it?  Plumbing is git-for-each-ref, 
and it has sorting options).

Paolo

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

[Brandon Casey]

Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 6 Jun 2008, Paolo Bonzini wrote:
> 
>>> What about people preferring the status quo?  I think a command line 
>>> option would be in order.'
>> config option seems more useful.
> 
> Except, of course, if you have a script that wants to override whatever 
> the user set in her config.

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)

Is there some legitimate function that depends on the order of listed
branches (or tags)?

Rather this seems like one of those things where everyone should either
welcome the functionality or be indifferent to it. Adding yet another
toggle for this sort of user-interface tweak seems like over-kill. It is
not costless, it adds complexity to the code and to the user interface.

If someone wants to list their branches alphabetically, or reverse
alphabetically, or if they only want to see branches beginning with 'BUG-',
why isn't it enough to just use the functionality provided by the command line?

bikeshedmode = off

-brandon

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

[Cedric Vivier]

On Fri, Jun 6, 2008 at 11:04 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> 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.
If natural sort is the default order though then piping through sort
to get things in "non-natural" order is easy enough indeed.

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

[Brandon Casey]

Cedric Vivier wrote:
> On Fri, Jun 6, 2008 at 11:04 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> 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.
> If natural sort is the default order though then piping through sort
> to get things in "non-natural" order is easy enough indeed.

Yes, that's what I meant.

-brandon

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

[しらいしななこ]

Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:

> Hi,
>
> On Fri, 6 Jun 2008, Paolo Bonzini wrote:
>
>> > What about people preferring the status quo?  I think a command line 
>> > option would be in order.'
>> 
>> config option seems more useful.
>
> Except, of course, if you have a script that wants to override whatever 
> the user set in her config.

But I think that is not an issue.  Isn't "git branch" a Porcelain?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2

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

[Johannes Schindelin]

Hi,

On Fri, 6 Jun 2008, Cedric Vivier wrote:

> On Fri, Jun 6, 2008 at 11:04 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> > 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

Hth,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 6 Jun 2008, Cedric Vivier wrote:
>
>> On Fri, Jun 6, 2008 at 11:04 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> > 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

That's Numeric sort, isn't it?

I sometimes dreamed of having "sort --random" for testing purposes ;-)

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

[Asheesh Laroia]

On Fri, 6 Jun 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Fri, 6 Jun 2008, Cedric Vivier wrote:
>>
>>> On Fri, Jun 6, 2008 at 11:04 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>>>> 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
>
> That's Numeric sort, isn't it?
>
> I sometimes dreamed of having "sort --random" for testing purposes ;-)

I use "bogosort -n" for that.

-- Asheesh.

-- 
We are the people our parents warned us about.

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

[Cedric Vivier]

On Sat, Jun 7, 2008 at 1:06 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> On Fri, Jun 6, 2008 at 11:04 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> > 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.

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

[Junio C Hamano]

"Cedric Vivier" <cedricv@neonux.com> writes:

> On Sat, Jun 7, 2008 at 1:06 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>>> On Fri, Jun 6, 2008 at 11:04 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>>> > 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.

[Cedric Vivier]

On Sat, Jun 7, 2008 at 2:17 AM, Junio C Hamano <gitster@pobox.com> 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.

[Jeff King]

On Fri, Jun 06, 2008 at 04:11:13PM -0700, Junio C Hamano wrote:

> I sometimes dreamed of having "sort --random" for testing purposes ;-)

perl -MList::Util=shuffle -e 'print shuffle <>'

-Peff

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

[Junio C Hamano]

"Cedric Vivier" <cedricv@neonux.com> writes:

> On Sat, Jun 7, 2008 at 2:17 AM, Junio C Hamano <gitster@pobox.com> 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 (?)

Yes, and we have precedents to it, like compat/strcasestr.c

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

[Andreas Ericsson]

Cedric Vivier wrote:
> 
> I've found a discussion on the Apache mailing-list where the author,
> Martin Pool seems to ack that this is ok to include his code in GPL'ed
> code or even to relicense it :
> http://lists.debian.org/debian-glibc/2003/10/msg00016.html
> 

AFAIU, that's the same as putting it in the public domain.

> Also maybe we could use glibc's strverscmp instead, but am not sure of
> its portability ?

glibc is extremely portable. In particular the code that doesn't require
anything in particular from the OS (which strvercmp() really shouldn't).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Ask Bjørn Hansen]

Not to pick on anyone in particular, but as a casual reader of the  
list just having read the 25 replies this patch got I feel compelled  
to send a link to the original "any colour of bikeshed will do" mail.

	http://xrl.us/b7g9d (Link to www.freebsd.org)
	or http://www.bikeshed.com/	



  - ask

-- 
http://develooper.com/ - http://askask.com/