patcht0000: check whether the shell supports the "local" keyword

> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> This has been discussed on the mailing list [1,2].
>
> Michael
>
> [1] https://public-inbox.org/git/CAPig+cRLB=dGD=+Af=yYL3M709LRpeUrtvcDLo9iBKYy2HAW-w@mail.gmail.com/
> [2] https://public-inbox.org/git/20160601163747.GA10721@sigill.intra.peff.net/
>
>  t/t0000-basic.sh | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>
> diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
> index 1aa5093f36..7fd87dd544 100755
> --- a/t/t0000-basic.sh
> +++ b/t/t0000-basic.sh
> @@ -20,6 +20,31 @@ modification *should* take notice and update the test vectors here.
>
>  . ./test-lib.sh
>
> +try_local_x () {
> +       local x="local" &&
> +       echo "$x"
> +}
> +
> +# This test is an experiment to check whether any Git users are using
> +# Shells that don't support the "local" keyword. "local" is not
> +# POSIX-standard, but it is very widely supported by POSIX-compliant
> +# shells, and if it doesn't cause problems for people, we would like
> +# to be able to use it in Git code.
> +#
> +# For now, this is the only test that requires "local". If your shell
> +# fails this test, you can ignore the failure, but please report the
> +# problem to the Git mailing list <git@vger.kernel.org>, as it might
> +# convince us to continue avoiding the use of "local".
> +test_expect_success 'verify that the running shell supports "local"' '
> +       x="notlocal" &&
> +       echo "local" >expected1 &&
> +       try_local_x >actual1 &&
> +       test_cmp expected1 actual1 &&
> +       echo "notlocal" >expected2 &&
> +       echo "$x" >actual2 &&
> +       test_cmp expected2 actual2
> +'
> +
>  ################################################################
>  # git init has been done in an empty repository.
>  # make sure it is empty.
> --
> 2.14.1

> On Thu, Oct 26, 2017 at 4:18 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Add a test balloon to see if we get complaints from anybody who is
>> using a shell that doesn't support the "local" keyword. If so, this
>> test can be reverted. If not, we might want to consider using "local"
>> in shell code throughout the git code base.
>
> I would guess that the number of people who actually run the Git test
> suite is microscopic compared to the number of people who use Git
> itself. It is not clear, therefore, that lack of reports of failure of
> the new test would imply that "local" can safely be used throughout
> the Git code base. At best, it might indicate that "local" can be used
> in the tests.
>
> Or, am I missing something?
>

> On Thu, Oct 26, 2017 at 1:28 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Thu, Oct 26, 2017 at 4:18 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> Add a test balloon to see if we get complaints from anybody who is
>>> using a shell that doesn't support the "local" keyword. If so, this
>>> test can be reverted. If not, we might want to consider using "local"
>>> in shell code throughout the git code base.
>>
>> I would guess that the number of people who actually run the Git test
>> suite is microscopic compared to the number of people who use Git
>> itself. It is not clear, therefore, that lack of reports of failure of
>> the new test would imply that "local" can safely be used throughout
>> the Git code base. At best, it might indicate that "local" can be used
>> in the tests.
>>
>> Or, am I missing something?
>>
> 
> I don't think you're missing anything. I think the idea here is: "do
> any users who actively run the test suite care if we start using
> local". I don't think the goal is to allow use of local in non-test
> suite code. At least, that's not how I interpreted it.
> 
> Thus it's fine to be only as part of a test and see if anyone
> complains, since the only people affected would be those which
> actually run the test suite...
> 
> Changing our requirement for regular shell scripts we ship seems a lot
> trickier to gauge.

> I don't think you're missing anything. I think the idea here is: "do
> any users who actively run the test suite care if we start using
> local". I don't think the goal is to allow use of local in non-test
> suite code. At least, that's not how I interpreted it.
>
> Thus it's fine to be only as part of a test and see if anyone
> complains, since the only people affected would be those which
> actually run the test suite...
>
> Changing our requirement for regular shell scripts we ship seems a lot
> trickier to gauge.

> Add a test balloon to see if we get complaints from anybody who is
> using a shell that doesn't support the "local" keyword. If so, this
> test can be reverted. If not, we might want to consider using "local"
> in shell code throughout the git code base.
> 
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> This has been discussed on the mailing list [1,2].