Re: [PATCH 1/2] parse-options: allow for configuring option abbreviation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

The config system is more flexible in every way. You can set it
system-wide, user-wide, repo-wide etc., and if you want exactly the
scope of an env variable you can do that too, just start your script
with:

    # These "''" quotes are not a mistake, it needs to be like this
    export GIT_CONFIG_PARAMETERS="'core.abbreviatedOptions=false'"
    git <some-cmd> [...]

So the reason we have GIT_TEST_* is pretty much because we can't just
whitelist GIT_CONFIG_PARAMETERS for the test suite, and to make it
obvious what test modes we have available.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux