Matthias Lederhofer wrote: > If filters use variables with the same name as variables > used in the script the script breaks. Executing the filters > in a separate process prevents accidential modification of > the variables in the main process. > @@ -349,21 +349,21 @@ while read commit; do > > eval "$(set_ident AUTHOR <../commit)" > eval "$(set_ident COMMITTER <../commit)" > - eval "$filter_env" < /dev/null > + sh -c "$filter_env" < /dev/null NACK. The eval is on purpose here. $filter_env must be able export GIT_AUTHOR* and GIT_COMMITTER* variables here. Generally, it might be useful that one filter sets or exports variables that are then available for subsequent filters or the next commit. Therefore, I think it's actually a feature to have eval instead of sh -c even if there is a chance that the filter overwrites internal variables. -- Hannes - 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
