On Tue, Mar 26, 2019 at 5:48 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > 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[1] > >> + 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 variable. -- Duy
