All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Taylor Blau <me@ttaylorr.com>
Cc: gitster@pobox.com, git@vger.kernel.org
Subject: Re: [PATCH v2 1/2] builtin/config.c: treat type specifiers singularly
Date: Fri, 30 Mar 2018 09:41:48 -0400	[thread overview]
Message-ID: <20180330134148.GC29568@sigill.intra.peff.net> (raw)
In-Reply-To: <20180330052830.57251-1-me@ttaylorr.com>

On Fri, Mar 30, 2018 at 01:28:29AM -0400, Taylor Blau wrote:

> Internally, we represent `git config`'s type specifiers as a bitset
> using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
> allows for the representation of multiple type specifiers in the `int
> types` field, but this multi-representation is left unused.
> 
> In fact, `git config` will not accept multiple type specifiers at a
> time, as indicated by:
> 
>   $ git config --int --bool some.section
>   error: only one type at a time.
> 
> This patch uses `OPT_SET_INT` to prefer the _last_ mentioned type
> specifier, so that the above command would instead be valid, and a
> synonym of:
> 
>   $ git config --bool some.section
> 
> This change is motivated by two urges: (1) it does not make sense to
> represent a singular type specifier internally as a bitset, only to
> complain when there are multiple bits in the set. `OPT_SET_INT` is more
> well-suited to this task than `OPT_BIT` is. (2) a future patch will
> introduce `--type=<type>`, and we would like not to complain in the
> following situation:
> 
>   $ git config --int --type=int

I think you could just end here, since...

> Where--although the legacy and modern type specifier (`--int`, and
> `--type`, respectively) do not conflict--we would store the value of
> `--type=` in a `char *` and the `--int` as a bit in the `int` bitset.
> 
> In the above, when error-checking `if (types != && type_str)`, we do not
> check additionally whether or not these types are the same, and simply
> complain immediately. This change makes `--int` and `--type=int` a true
> synonym of each other, and removes the need for additional complexity,
> as above in the conditional.

None of this type_str stuff exists yet, and you've sufficiently
motivated the change.

> Signed-off-by: Taylor Blau <me@ttaylorr.com>
> ---
>  builtin/config.c       | 39 +++++++++++++++++----------------------
>  t/t1300-repo-config.sh | 11 +++++++++++
>  2 files changed, 28 insertions(+), 22 deletions(-)

The patch mostly looks good. We probably want to also rewrite the TYPE_*
#defines to be sequential, since somebody may scratch their head
wondering why we use one bit per type when we do not treat them as a
bitfield.

> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index 4f8e6f5fd..aa45b9267 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -1611,4 +1611,15 @@ test_expect_success '--local requires a repo' '
>  	test_expect_code 128 nongit git config --local foo.bar
>  '
>  
> +cat >.git/config <<-\EOF &&
> +[core]
> +number = 10
> +EOF
> +
> +test_expect_success 'later legacy specifiers are given precedence' '
> +	git config --bool --int core.number >actual &&
> +	echo 10 > expect &&
> +	test_cmp expect actual
> +'

Minor style nit: we prefer ">expect" with no space. Though t1300 is
certainly a cornucopia of style violations already. I could buy it under
the guise of matching existing style if there wasn't a counter-example
directly above. :)

We also prefer to put that "cat >.git/config" inside a test block,
though I'm pretty sure that _is_ following existing style in the test.

-Peff

  parent reply	other threads:[~2018-03-30 13:41 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 23:47 [PATCH] builtin/config.c: prefer `--type=bool` over `--bool`, etc Taylor Blau
2018-03-29 20:18 ` Junio C Hamano
2018-03-29 22:11 ` Jeff King
2018-03-30  5:27   ` Taylor Blau
2018-03-30 13:53     ` Jeff King
2018-03-30 16:00       ` Junio C Hamano
2018-03-30 18:27         ` Jeff King
2018-03-30  5:28 ` [PATCH v2 1/2] builtin/config.c: treat type specifiers singularly Taylor Blau
2018-03-30  5:28   ` [PATCH v2 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc Taylor Blau
2018-03-30  6:17     ` René Scharfe
2018-03-30 13:48     ` Jeff King
2018-03-30 13:41   ` Jeff King [this message]
2018-04-04  6:07 ` [PATCH v3 0/2] " Taylor Blau
2018-04-04  6:07   ` [PATCH v3 1/2] builtin/config.c: treat type specifiers singularly Taylor Blau
2018-04-04  7:57     ` Eric Sunshine
2018-04-05  1:53       ` Taylor Blau
2018-04-05 21:51         ` Jeff King
2018-04-04  6:07   ` [PATCH v3 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc Taylor Blau
2018-04-04  7:27     ` Eric Sunshine
2018-04-05  1:47       ` Taylor Blau
2018-04-05  2:00 ` [PATCH v4 0/2] " Taylor Blau
2018-04-05 21:58   ` Jeff King
2018-04-05 22:15     ` Taylor Blau
     [not found] ` <cover.1522893363.git.me@ttaylorr.com>
2018-04-05  2:00   ` [PATCH v4 1/2] builtin/config.c: treat type specifiers singularly Taylor Blau
2018-04-05  2:00   ` [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc Taylor Blau
2018-04-05 22:29     ` Eric Sunshine
2018-04-05 22:40       ` Jeff King
2018-04-06  5:19         ` Taylor Blau
2018-04-06  5:17       ` Taylor Blau
2018-04-05  2:02   ` Taylor Blau
2018-04-05 22:12     ` Jeff King
2018-04-05 22:15       ` Taylor Blau
2018-04-06  5:08       ` Taylor Blau
2018-04-06  6:38 ` [PATCH v6 0/2] builtin/config.c: support `--type=<type>` as preferred alias for `--type` Taylor Blau
     [not found] ` <cover.1522996619.git.me@ttaylorr.com>
2018-04-06  6:39   ` [PATCH v6 1/2] builtin/config.c: treat type specifiers singularly Taylor Blau
2018-04-06  6:39   ` [PATCH v6 2/2] builtin/config.c: support `--type=<type>` as preferred alias for `--type` Taylor Blau
2018-04-06  7:04     ` Eric Sunshine
2018-04-07  0:39       ` Taylor Blau
2018-04-07  8:25         ` Eric Sunshine
2018-04-09 22:46 ` [PATCH v7 0/2] " Taylor Blau
2018-04-09 23:11   ` Eric Sunshine
     [not found] ` <cover.1523313730.git.me@ttaylorr.com>
2018-04-09 22:46   ` [PATCH v7 1/2] builtin/config.c: treat type specifiers singularly Taylor Blau
2018-04-10  1:22     ` Junio C Hamano
2018-04-10  2:12       ` Taylor Blau
2018-04-10  4:13         ` Eric Sunshine
2018-04-09 22:46   ` [PATCH v7 2/2] builtin/config.c: support `--type=<type>` as preferred alias for `--type` Taylor Blau
2018-04-10  1:44     ` Junio C Hamano
2018-04-10  2:17       ` Taylor Blau
2018-04-11  1:06 ` [PATCH v8 0/2] " Taylor Blau
2018-04-11  1:24   ` Junio C Hamano
2018-04-11  1:33     ` Taylor Blau
2018-04-11  3:11       ` Junio C Hamano
2018-04-11  3:49         ` Taylor Blau
     [not found] ` <cover.1523408336.git.me@ttaylorr.com>
2018-04-11  1:06   ` [PATCH v8 1/2] builtin/config.c: treat type specifiers singularly Taylor Blau
2018-04-11  1:07   ` [PATCH v8 2/2] builtin/config.c: support `--type=<type>` as preferred alias for `--type` Taylor Blau
2018-04-18 21:43 ` [PATCH v9 0/2] " Taylor Blau
     [not found] ` <cover.1524087557.git.me@ttaylorr.com>
2018-04-18 21:43   ` [PATCH v9 1/2] builtin/config.c: treat type specifiers singularly Taylor Blau
2018-04-18 21:43   ` [PATCH v9 2/2] builtin/config.c: support `--type=<type>` as preferred alias for `--type` Taylor Blau
2018-04-19  2:47     ` Junio C Hamano
2018-04-19  3:01       ` Taylor Blau

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=20180330134148.GC29568@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.