git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v2 3/8] config: Use parseopt.
Date: Tue, 17 Feb 2009 15:55:51 +0200	[thread overview]
Message-ID: <94a0d4530902170555l4e3f769wa24513b0ffbdd6a0@mail.gmail.com> (raw)
In-Reply-To: <7vbpt1by1y.fsf@gitster.siamese.dyndns.org>

On Tue, Feb 17, 2009 at 4:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> +     if (HAS_MULTI_BITS(actions)) {
>> +             error("only one action at a time.");
>> +             usage_with_options(builtin_config_usage, builtin_config_options);
>
> My initial reaction was:
>
>        Can we easily say "--get and --getall are mutually incompatible"?
>
> and knowing that it would take much more code, the second reaction was:
>
>        Does the user know what we mean by "action"?
>
> Since the answer to this is "Yes, the usage message comes from parseopt
> and there is a clear categorization", I think the message is good enough.
>
> What happens when the user says "config --get --get-colorbool user.name"?
> Is it an error?  Is it diagnosed as an error?
>
> It probably is easy to fix it by defining two bits of fake actions and do:
>
>        if (get_color_slot)
>                actions |= ACTION_GET_COLOR;
>        if (get_colorbool_slot)
>                actions |= ACTION_GET_COLORBOOL;
>
> immediately before this HAS_MULTI_BITS check.
>
> I know I suggested these to are type-like, but I realize that these two
> are better categorized as actions tied to a specific type (color), as you
> had in your earlier round.

All right, done.

>> +     if (actions == 0)
>> +             switch (argc) {
>> +             case 1: actions |= ACTION_GET; break;
>> +             case 2: actions |= ACTION_ADD; break;
>> +             case 3: actions |= ACTION_REPLACE_ALL; break;
>
> Straight assignment, not ORing-in please.  It wastes a few seconds from
> the reader wondering what other bits in the variable "actions" are used
> for things other than ACTION_* (the answer is none).
>
> Similarly, later conditions:
>
>> +     if (actions & ACTION_LIST) {
>
> would read better if they used equality == checks.

Cool, I was worried those where not logical to the reader but I
couldn't think of a better solution... this one looks much better!

I've also made the same change for the 'types' variable in a later patch.

-- 
Felipe Contreras

  reply	other threads:[~2009-02-17 13:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-17  0:54 [PATCH v2 1/8] config: Trivial rename in preparation for parseopt Felipe Contreras
2009-02-17  0:54 ` [PATCH v2 2/8] config: Reorganize get_color* Felipe Contreras
2009-02-17  0:54   ` [PATCH v2 3/8] config: Use parseopt Felipe Contreras
2009-02-17  0:54     ` [PATCH v2 4/8] config: Disallow multiple variable types Felipe Contreras
2009-02-17  0:54       ` [PATCH v2 5/8] config: Disallow multiple config file locations Felipe Contreras
2009-02-17  0:54         ` [PATCH v2 6/8] config: Don't allow extra arguments for -e or -l Felipe Contreras
2009-02-17  0:54           ` [PATCH v2 7/8] config: Codestyle cleanups Felipe Contreras
2009-02-17  0:54             ` [PATCH v2 8/8] config: Cleanup editor action Felipe Contreras
2009-02-17  2:28               ` Junio C Hamano
2009-02-17  2:24       ` [PATCH v2 4/8] config: Disallow multiple variable types Junio C Hamano
2009-02-17  2:24     ` [PATCH v2 3/8] config: Use parseopt Junio C Hamano
2009-02-17 13:55       ` Felipe Contreras [this message]
2009-02-17  5:44     ` Junio C Hamano
2009-02-17 10:35       ` Felipe Contreras
2009-02-17 11:55         ` Johannes Schindelin
2009-02-17 13:21           ` Felipe Contreras
2009-02-17  1:00   ` [PATCH v2 2/8] config: Reorganize get_color* Felipe Contreras
2009-02-17  2:24   ` Junio C Hamano
2009-02-17  1:45 ` [PATCH v2 1/8] config: Trivial rename in preparation for parseopt Junio C Hamano
2009-02-17  2:42   ` Felipe Contreras
2009-02-17 12:01     ` Johannes Schindelin
2009-02-17 13:59       ` Felipe Contreras
2009-02-17  9:00   ` Gerrit Pape
2009-02-17 11:58     ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94a0d4530902170555l4e3f769wa24513b0ffbdd6a0@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).