Re: [PATCH] setup: support GIT_IGNORE_INSECURE_OWNER environment variable

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Mon, Jul 01, 2024 at 06:34:10PM +0200, Johannes Schindelin wrote:
>
>> The `local_repo_env` array _specifically_ lists `GIT_CONFIG_PARAMETERS` in
>> https://github.com/git/git/blob/v2.45.2/environment.c#L129 to be removed
>> from the environment when spawning the `git upload-pack` process.
>> 
>> It was not originally listed, but added via
>> https://lore.kernel.org/git/20100824064114.GA20724@burratino/, where the
>> commit message does not really shed light into the question why this was
>> desirable, and there is no discussion in that mail thread about this
>> aspect of the patch, but at least the added test case reveals the
>> intention in some sort of way: The `-c` option allows to specify
>> `receive.denyDeletes`, and in the described scenario the idea was that it
>> would only apply to the client side of a local `receive-pack` but not the
>> "remote" one. As the example above illustrates, that patch might have
>> been overly focused on one specific, particular scenario.
>
> One reason we haven't loosened local_repo_env for the local transport is
> that it would make it inconsistent with all of the other transports.
> I.e., "git -c foo.bar=baz fetch" would still be ignored over ssh, https,
> and so on, because those transports don't pass environment variables.
>
> There's some more discussion from a similar case that came up a month
> ago:
>
>   https://lore.kernel.org/git/20240529102307.GF1098944@coredump.intra.peff.net/

Thanks.  I wonder if there is a way to add this kind of pieces of
information to old commits and discussion threads around it after
the fact, and if it helps us (like Dscho who wondered why we decided
if it is a good idea, and more importantly if we still think it is a
good idea and why).

    ... and then goes back to see the original discussion thread,
    with the "bright idea" that I could just follow up on 14-year
    old discussion thread.  Only to find that despite what Dscho
    said, the commit message does say why it is desirable ("to
    imitate remote transport well") already.

So, I guess we do not really need to do such a post-annotation in
this particular case, but I think after seeing somebody posting a
message like the one I am responding to and finding it helpful, it
would be helpful if somebody can post a message pointing at it as a
response to the old thread that wants a post-annotation.