From: Eric Rannaud <eric.rannaud@gmail.com>
Date: Tue, 16 May 2017 16:59:03 GMT
Subject: Re: git rebase regression: cannot pass a shell expression directly to --exec
Message-ID: <CA+zRj8Uxh1SGdVW=zz29Q4m4OnDcs665T0XtV6FiZ_qZSiG-8g@mail.gmail.com>
In-Reply-To: <20170516161858.stp4ylwfmbgc4oid@sigill.intra.peff.net>

On Tue, May 16, 2017 at 9:18 AM, Jeff King <peff@peff.net> wrote:
> On Tue, May 16, 2017 at 12:23:02PM +0200, Johannes Schindelin wrote:
>> It would appear to me that you used a side effect of an implementation
>> detail: that `git rebase -i` was implemented entirely as a shell script.
>
> I don't think that's true at all. He expected the user-provided "--exec"
> command to be run by a shell, which seems like a reasonable thing for
> Git to promise (and we already make a similar promise for most
> user-provided commands that we run).  What happens in between, be it

As a "user", my expectation was simply that the command would be run
not just in "a shell", but in *my* shell (or the shell that calls git,
maybe). So I don't see any portability question with respect to Git.
My script that uses git rebase --exec may not be portable, but that's
my problem.

When I use "git rebase --exec <cmd>" I'm basically writing a "foreach
commit in range { <cmd> }" in my shell. Same idea with git bisect run.

A transparent optimization that tries execve() then falls back to the
user's shell sounds like a good idea.