On Tue, May 16, 2017 at 1:12 PM, Johannes Schindelin
wrote:
>>
>> I think it would be better to just
>>
>> (a) get rid of the magic strcspn() entirely
>>
>> (b) make the 'can we optimize this' test be simply just looking up
>> 'argv[0]' in $PATH
>
> What about
>
> ABC=1 my-executable my-
Hi Linus,
On Tue, 16 May 2017, Linus Torvalds wrote:
> On Tue, May 16, 2017 at 10:23 AM, Jeff King wrote:
> >
> > I think the logic here would be more like:
> >
> > 1. During prepare_shell_cmd(), even if we optimize out the shell call,
> > still prepare a fallback argv (since we can't all
On Tue, May 16, 2017 at 10:23 AM, Jeff King wrote:
>
> I think the logic here would be more like:
>
> 1. During prepare_shell_cmd(), even if we optimize out the shell call,
> still prepare a fallback argv (since we can't allocate memory
> post-fork).
>
> 2. In the forked child, if we
On Tue, May 16, 2017 at 10:29:31AM -0700, Eric Rannaud wrote:
> > 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,
On Tue, May 16, 2017 at 10:21:51AM -0700, Eric Rannaud wrote:
> On Tue, May 16, 2017 at 9:59 AM, Eric Rannaud wrote:
> > When I use "git rebase --exec " I'm basically writing a "foreach
> > commit in range { }" in my shell. Same idea with git bisect run.
> >
> > A transparent optimization that t
Jeff King wrote:
>>> On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote:
One hack would be to look for BASH_FUNC_* in the environment and disable
the optimization in that case. I think that would make your case Just
Work. It doesn't help other oddball cases, like:
[...]
>> Hm
On 05/16, Jeff King wrote:
> On Tue, May 16, 2017 at 10:15:40AM -0700, Brandon Williams wrote:
>
> > > > > So I was thinking something like the patch below, though I guess
> > > > > technically you could look for BASH_FUNC_$argv[0]%%, which seems to be
> > > > > bash's magic variable name. I hate
On Tue, May 16, 2017 at 10:14 AM, Kevin Daudt 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
On Tue, May 16, 2017 at 10:15:40AM -0700, Brandon Williams wrote:
> > > > So I was thinking something like the patch below, though I guess
> > > > technically you could look for BASH_FUNC_$argv[0]%%, which seems to be
> > > > bash's magic variable name. I hate to get too intimate with those
> > >
On Tue, May 16, 2017 at 9:59 AM, Eric Rannaud wrote:
> When I use "git rebase --exec " I'm basically writing a "foreach
> commit in range { }" 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 id
On 05/16, Jeff King wrote:
> On Tue, May 16, 2017 at 09:41:24AM -0700, Jonathan Nieder wrote:
>
> > Jeff King wrote:
> > > On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote:
> >
> > >> One hack would be to look for BASH_FUNC_* in the environment and disable
> > >> the optimization in that
On Tue, May 16, 2017 at 09:59:03AM -0700, Eric Rannaud wrote:
> On Tue, May 16, 2017 at 9:18 AM, Jeff King 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` w
On Tue, May 16, 2017 at 9:47 AM, Jeff King wrote:
>> I think we want to behave consistently for shell builtins and for
>> exported functions --- they are different sides of the same problem,
>> and behaving differently between the two feels confusing.
>
> Yes, I think ideally we'd handle it all tr
On Tue, May 16, 2017 at 9:18 AM, Jeff King 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 tr
On Tue, May 16, 2017 at 09:41:24AM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote:
>
> >> One hack would be to look for BASH_FUNC_* in the environment and disable
> >> the optimization in that case. I think that would make your case
On Mon, May 15, 2017 at 8:53 PM, Jeff King wrote:
>> > So I suspect if you added an extraneous semi-colon, your case would work
>> > again (and that would confirm for us that this is indeed the problem).
>>
>> Wow, that's a brilliant analysis.
>
> If it's right. :) It's all theory at this point.
>
(+Brandon Williams, who may have more context for execvp-related things)
Hi,
Jeff King wrote:
> On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote:
>> One hack would be to look for BASH_FUNC_* in the environment and disable
>> the optimization in that case. I think that would make your cas
On Tue, May 16, 2017 at 12:23:02PM +0200, Johannes Schindelin wrote:
> On Mon, 15 May 2017, Eric Rannaud wrote:
>
> > It used to be possible to run a sequence like:
> >
> > foo() { echo X; }
> > export -f foo
> > git rebase --exec foo HEAD~10
>
> It would appear to me that you used a side
Hi Junio,
On Tue, 16 May 2017, Junio C Hamano wrote:
> The point of rewriting things in C and using run_command() interface was
> to avoid shell overhead.
That statement is missing the point.
It is true that converting shell scripts to proper builtins avoids the
shell overhead.
It is even more
Hi Eric,
On Mon, 15 May 2017, Eric Rannaud wrote:
> It used to be possible to run a sequence like:
>
> foo() { echo X; }
> export -f foo
> git rebase --exec foo HEAD~10
It would appear to me that you used a side effect of an implementation
detail: that `git rebase -i` was implemented enti
On Mon, May 15, 2017 at 11:53:57PM -0400, Jeff King wrote:
> My /bin/sh isn't bash, but I should be able to build with
> SHELL_PATH=/bin/bash to reproduce. But I can't:
>
>$ bash
>$ foo() { echo >&2 "in foo"; }
>$ export -f foo
>$ bash -c foo
>in foo
>
>$ strace -f 2>&1 g
On Tue, May 16, 2017 at 12:40:51PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Interesting. The "exec" string is still run with a shell. E.g.:
> > ...
> > I wonder if this is falling afoul of the optimization in run-command's
> > prepare_shell_cmd() to skip shell invocations for "simp
Jeff King writes:
> Interesting. The "exec" string is still run with a shell. E.g.:
> ...
> I wonder if this is falling afoul of the optimization in run-command's
> prepare_shell_cmd() to skip shell invocations for "simple" commands.
> ...
> So I suspect if you added an extraneous semi-colon, you
On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote:
> One hack would be to look for BASH_FUNC_* in the environment and disable
> the optimization in that case. I think that would make your case Just
> Work. It doesn't help other oddball cases, like:
>
> - you're trying to run a shell bui
On Mon, May 15, 2017 at 11:08:39AM -0700, Eric Rannaud wrote:
> It used to be possible to run a sequence like:
>
> foo() { echo X; }
> export -f foo
> git rebase --exec foo HEAD~10
>
> Since upgrading to 2.13.0, I had to update my scripts to run:
>
> git rebase --exec "bash -c foo" HEAD
Hi all,
It used to be possible to run a sequence like:
foo() { echo X; }
export -f foo
git rebase --exec foo HEAD~10
Since upgrading to 2.13.0, I had to update my scripts to run:
git rebase --exec "bash -c foo" HEAD~10
I'm not sure if this was an intended change. Bisecting with the
fol
26 matches
Mail list logo
