On Fri, Mar 30, 2018 at 04:23:56PM -0400, Eric Sunshine wrote: > On Wed, Mar 28, 2018 at 9:16 PM, Taylor Blau <me@xxxxxxxxxxxx> 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. > > 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. > > 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
