From: David Kastrup <dak@gnu.org>
Date: Fri, 06 Jul 2007 08:06:51 GMT
Subject: Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
Message-ID: <863b02j6qs.fsf@lola.quinscape.zz>
In-Reply-To: <468DE9F3.B4489CDE@eudaptics.com>

Johannes Sixt <J.Sixt@eudaptics.com> writes:

> Johannes Schindelin wrote:
>> -       sed -e '1,/^$/d' <../commit | \
>> -               eval "$filter_msg" | \
>> -               sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
>> -                       $parentstr > ../map/$commit
>> +       (sed -e '1,/^$/d' <../commit |
>> +               (eval "$filter_msg" ||
>> +                die "msg filter failed: $filter_msg" 2>&3) |
>> +               (sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
>> +                       $parentstr > ../map/$commit ||
>> +                die "commit filter failed: $filter_commit" 2>&3)) 3>&1 |
>> +        grep . && die
>
> You introduce a handful of new forks and an exec. Isn't an intermediate
> file much cheaper?

The number of forks can be reduced by using { ...; } instead of (
... ) here (though it is possible the shell optimizes them away).
grep . should likely redirect its output with >&2 so that it ends up
on stderr.  I'd probably prefer grep ^ or grep '' since that matches
empty lines as well.  When done that way, I don't see a "handful of
new forks".

Instead of "grep ." one could also do something like

if read line then
  while echo "$line" && read line; do :; done
  die
fi

which is fork-less.

-- 
David Kastrup