Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
