Re: git rebase regression: cannot pass a shell expression directly to --exec
- From
- Eric Rannaud <eric.rannaud@gmail.com>
- Date
- May 16, 2017, 16:59 UTC
- 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:
Show 8 quoted lines
> 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.