From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 7B853201A4 for ; Tue, 16 May 2017 17:14:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752349AbdEPROQ (ORCPT ); Tue, 16 May 2017 13:14:16 -0400 Received: from ikke.info ([178.21.113.177]:48240 "EHLO vps892.directvps.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751567AbdEPROP (ORCPT ); Tue, 16 May 2017 13:14:15 -0400 Received: by vps892.directvps.nl (Postfix, from userid 1008) id 2D2D94400AE; Tue, 16 May 2017 19:14:14 +0200 (CEST) Date: Tue, 16 May 2017 19:14:14 +0200 From: Kevin Daudt To: Eric Rannaud Cc: Jeff King , Johannes Schindelin , git@vger.kernel.org, Jeremy Serror Subject: Re: git rebase regression: cannot pass a shell expression directly to --exec Message-ID: <20170516171414.GC2169@alpha.vpn.ikke.info> References: <20170516161858.stp4ylwfmbgc4oid@sigill.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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` 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 " 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 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).