Re: [PATCH 1/2] parse-options: allow for configuring option abbreviation
- Date: Tue, 26 Mar 2019 11:14:05 +0700
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: Re: [PATCH 1/2] parse-options: allow for configuring option abbreviation
On Tue, Mar 26, 2019 at 5:48 AM Ævar Arnfjörð Bjarmason
> On Mon, Mar 25 2019, Eric Sunshine wrote:
> > On Mon, Mar 25, 2019 at 4:23 PM Ævar Arnfjörð Bjarmason
> > <avarab@xxxxxxxxx> wrote:
> >> diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt
> >> @@ -1,3 +1,15 @@
> >> +core.abbreviatedOptions::
> >> + Defaults to `true` which allows options to be abbreviated as
> >> + long as they aren't ambiguous, e.g. for linkgit:git-init
> >> + the `--bare` option can be abbreviated as `--bar`, `--ba` or
> >> + even `--b` since no other option starts with those
> >> + prefixes. However, if such an option were added in the future
> >> + any use of these abbreviations would break.
> >> ++
> >> +By setting this to false (e.g. in scripts) you can defend against such
> >> +future breakages by enforcing that options must always be fully
> >> +provided.
> > I don't get why having a configuration option is better for defending
> > scripts against this problem than a simple environment variable. It
> > seems easier for the script prologue to contain:
> > GIT_TEST_ABBREVIATED_OPTIONS=false
> > export GIT_TEST_ABBREVIATED_OPTIONS
> > than for it to muck about with git-config or use "git -c
> > core.abbreviatedOptions=false ..." everywhere. The commit message
> > doesn't do a good enough job of justifying the configuration option
> > over the environment variable.
> > Also, if this is now intended to be more general (aiding script
> > writers) than just being for our test suite, then dropping "TEST" from
> > the name seems warranted:
> > GIT_ABBREVIATED_OPTIONS
> If we want to make something user-configurable we tend to add config
> variables. The GIT_TEST_* variables are only intended for our own test
> suite, see t/README.
> I don't mind documenting this, but it's a well-established pattern, so
> if we're going to describe how this works/why use one or the other it
> should probably be some other series to t/README and/or git-config.txt
> We traditionally *only* expose this sort of thing to users via config,
> and not via env variables.
If this is mostly useful for scripts then I agree with Eric an
environment variable is the way to go. A configuration variable does
not make it more convenient.
And no we don't only export via config. There are a bunch of public
env variables in git.txt. "core" namespace is already very crowded. If
this one is only rarely used, I'd rather not add a new config