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 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



[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