Re: [PATCH RFC] cherry: support --abbrev option

> Am 15.03.2010 17:03, schrieb Erik Faye-Lund:
>> Switch to parse-options API while we're at it.
>>
>> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
>> ---
>>
>> I sometimes find it useful to look at the commit-subject together with
>> the SHA-1s. Using --abbrev increases the chance that the lines fits on
>> an 80 character wide terminal, making the output easier to read.
>>
>>  builtin/log.c |   40 ++++++++++++++++++++++------------------
>>  1 files changed, 22 insertions(+), 18 deletions(-)
>>
>> diff --git a/builtin/log.c b/builtin/log.c
>> index b70d0f7..020d618 100644
>> --- a/builtin/log.c
>> +++ b/builtin/log.c
>> @@ -1286,8 +1286,11 @@ static int add_pending_commit(const char *arg, struct rev_info *revs, int flags)
>>       return -1;
>>  }
>>
>> -static const char cherry_usage[] =
>> -"git cherry [-v] [<upstream> [<head> [<limit>]]]";
>> +static const char * const cherry_usage[] = {
>> +     "git cherry [-v] [<upstream> [<head> [<limit>]]]",
>> +     NULL
>> +};
>> +
>>  int cmd_cherry(int argc, const char **argv, const char *prefix)
>>  {
>>       struct rev_info revs;
>> @@ -1298,26 +1301,26 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
>>       const char *upstream;
>>       const char *head = "HEAD";
>>       const char *limit = NULL;
>> -     int verbose = 0;
>> +     int verbose = 0, abbrev = 40;
>>
>> -     if (argc > 1 && !strcmp(argv[1], "-v")) {
>> -             verbose = 1;
>> -             argc--;
>> -             argv++;
>> -     }
>> +     struct option options[] = {
>> +             OPT__ABBREV(&abbrev),
>> +             OPT__VERBOSE(&verbose),
>> +             OPT_END()
>> +     };
>
> If I use --no-abbrev, do I get 0 or 40 hash chars?  I didn't actually
> test it, but I suspect an "if (!abbrev) abbrev = 40;" is needed somewhere.
>

>> -     if (argc > 1 && !strcmp(argv[1], "-h"))
>> -             usage(cherry_usage);
>> +     argc = parse_options(argc, argv, prefix, options, cherry_usage,
>> +         PARSE_OPT_KEEP_UNKNOWN);
>
> Why do you use PARSE_OPT_KEEP_UNKNOWN here? I think the old option
> parsing code lazily relied on invalid options being found out by
> add_pending_commit() later. We can be lazy again by leaving invalid
> option handling to parse_options(); sure, it changes the error message,
> but for the better.