From: Eric Rannaud <eric.rannaud@gmail.com>
Date: Tue, 16 May 2017 17:29:31 GMT
Subject: Re: git rebase regression: cannot pass a shell expression directly to --exec
Message-ID: <CA+zRj8WFuqaNV_6U5=VUrEmeQ_fNaRs8mKxdSd=Z0QMyGk4pHw@mail.gmail.com>
In-Reply-To: <20170516171414.GC2169@alpha.vpn.ikke.info>

On Tue, May 16, 2017 at 10:14 AM, Kevin Daudt <me@ikke.info> wrote:
>> A transparent optimization that tries execve() then falls back to the
>> user's shell sounds like a good idea.
>
> It does not really work that way. Git runs in a separate process that
> does not have access to your current shell. That's why you need to do
> 'export -f foo'.
>
> If you want git to be able to ecute the foo shell function, git needs to
> start a _new_ shell process, which reads the environment, recognize the
> exported function and run that.
>
> This is not the same as git executing the command in your shell. Not
> exported variables would not be available in this function (as it would
> be in your equivalent).

I'm sorry, I didn't mean (or say) "my shell process". Indeed, it
doesn't work that way. And to be clear, there is no problem with
having to "export -f foo". The only question is how should git run the
<cmd> passed to --exec: should it run directly or using a shell?