Re: [PATCH 0/4] Drop git-exec-path from non-Git child programs

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

 



On Thu, May 22, 2025 at 9:21 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
>
> Hi Ben
>
> On 20/05/2025 20:34, D. Ben Knoble wrote:
> > This has caused trouble in the past [1] [2];
>
> Another way of looking at this is that the trouble is caused by a script
> that makes incorrect assumptions about git.

I've come around on this idea since fixing my setup to not assume
contrib scripts are installed relative to Git (rather, I've hardcoded
assumptions about where they get installed by my package manager).

>
> The assumption that the scripts from contrib as installed at a fixed
> location relative to the git binary is false. Where they are installed
> and whether they are installed at all is down to the discretion of the
> distribution that you're using. Looking for "git jump" at a fixed offset
> from the git binary is no more portable than looking for it in a fixed
> location.
>
> I think that the assumption that git should not change the environment
> when it runs the editor is unrealistic. "git commit file" will use a
> temporary index to create the commit and sets GIT_INDEX_FILE when
> running the editor. This means that if the editor wants to display the
> staged changes by running "git diff --cached HEAD" the diff will
> accurately represent the changes being committed. Adding GIT_EXEC_PATH
> to the beginning of PATH ensures that the diff will be created by the
> same version of git the the user ran which avoids subtle bugs where a
> sub-process of git runs a git command using an incompatible version of
> git. There are several other environment variables that may be set when
> running the editor such as GIT_DIR if the command is run from a linked
> wortree.
>
> To create a clean environment when opening a terminal from your editor
> you can add
>
>      PATH="${PATH#$GIT_EXEC_PATH:}"
>      unset $(git rev-parse --local-env-vars)
>
> to your shell setup script.
>
> I think the first two patches are very welcome cleanups but I'm not
> convinced by the rationale for patches 3 & 4.

So I'll resend the first 2 cleanups and drop the rest.





[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