Re: [PATCH v3 1/3] builtin/config: introduce `--default`

From: Taylor Blau <me@ttaylorr.com>
Date: Apr 5, 2018, 02:46 UTC
Message-ID: <20180405024626.GB31883@syl.local>
In-Reply-To: <CAPig+cSk_H-Dh585JsynNfp1GSuXSkKay0Vo3Jhda6-vPdi6Uw@mail.gmail.com>

On Fri, Mar 30, 2018 at 04:23:56PM -0400, Eric Sunshine wrote:

Show 11 quoted lines

> On Wed, Mar 28, 2018 at 9:16 PM, Taylor Blau <me@ttaylorr.com> wrote:
> > This commit (and those following it in this series) aim to eventually
> > replace `--get-color` with a consistent alternative. By introducing
> > `--default`, we allow the `--get-color` action to be promoted to a
> > `--color` type specifier, retaining the "fallback" behavior via the
> > `--default` flag introduced in this commit.
>
> I'm confused. The cover letter said that this iteration no longer
> introduces a --color option (favoring instead --type=color), but this
> commit message still talks about --color. Did you mean
> s/--color/--type=color/ ?

My mistake; I think I rebased this series off of the "--type=" series and forgot to amend this change. I have updated this and the below in the subsequent re-roll.

Show 9 quoted lines

> > For example, we aim to replace:
> >
> >   $ git config --get-color slot [default] [...]
> >
> > with:
> >
> >   $ git config --default default --color slot [...]
>
> Ditto: s/--color/--type=color/

Ack.

Show 14 quoted lines

> > Values filled by `--default` behave exactly as if they were present in
> > the affected configuration file; they will be parsed by type specifiers
> > without the knowledge that they are not themselves present in the
> > configuration.
> >
> > Specifically, this means that the following will work:
> >
> >   $ git config --int --default 1M does.not.exist
> >   1048576
> >
> > In subsequent commits, we will offer `--color`, which (in conjunction
> > with `--default`) will be sufficient to replace `--get-color`.
>
> Ditto: s/--color/--type=color/

Ack.

Thanks, Taylor