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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 5, 2008, 19:29 UTC
Message-ID: <7vprqv1y0w.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0806051946100.21190@racer>

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

Show 47 quoted lines

> 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.