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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
