Hi, Richard Hartmann wrote: > Spawning a new subprocess for every line printed is inefficient. > Use heredoc, instead. I think this makes sense as a code clarity, simplicity, and internationalizability improvement, but don't like the precedent of eliminating 'echo' for the sake of fork removal (unless we have measurements showing it's worthwhile, which would be included here). Maybe a simpler commit message could sidestep the issue? Use a heredoc instead of an "echo" for each line. > Based on 98770971aef8d1cbc78876d9023d10aa25df0526 in original patch > series from 2013-06-10. Please don't include this. The audience for the commit message doesn't have that commit to compare to. If you want to preserve the original date, the way to do that is a "Date:" field at the top of the message body. Date: Fri, 28 Jun 2013 21:16:19 +0530 Spawning a new subprocess for ... [...] > --- a/templates/hooks--pre-commit.sample > +++ b/templates/hooks--pre-commit.sample > @@ -31,18 +31,19 @@ if [ "$allownonascii" != "true" ] && > test $(git diff --cached --name-only --diff-filter=A -z $against | > LC_ALL=C tr -d '[ -~]\0' | wc -c) != 0 > then > - echo "Error: Attempt to add a non-ascii file name." > - echo > - echo "This can cause problems if you want to work" > - echo "with people on other platforms." > - echo > - echo > - echo "If you know what you are doing you can disable this" > - echo "check using:" > - echo > - echo " git config hooks.allownonascii true" > - echo > + cat <<-EOF > +Error: Attempt to add a non-ascii file name. Using cat <<\EOF would make reading easier since the reader then doesn't have to worry about whether the text being cat'ed is indented or uses variable substitutions. > - echo "To be portable it is advisable to rename the file ..." > +To be portable it is advisable to rename the file. Yes, nice. With the above nits addressed, this change looks to be going in the right direction. Thanks. Hope that helps, Jonathan -- 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