Bug report: Duplicate CRLF rewrite warnings on commit

If you use .gitattributes to enable CRLF->LF rewriting, then commit a file that would have its line endings rewritten, the "CRLF will be replaced by LF" warning is printed several times over; I'd expect it to be printed only once.

There's a test case in t0020 -- "safecrlf: print warning only once" -- that checks the warning is only printed once when using `git add`, but nothing that seems to check the same thing on `git commit`. The unnecessary multiple warnings seem to have existed since at least v1.6.0 (the warnings appear to have been added in v1.5.5 in 21e5ad5, but I couldn't get that to build on my current box), and I'm seeing them on my Cygwin box's build of the current next branch (d10caa2) and on my CentOS box's v2.8.1 release.

Example:

    $ git init
    Initialized empty Git repository in /home/Adam/test/.git/

    $ echo '* text' >.gitattributes

    $ echo 'lf-terminated line' >text

    $ git add .gitattributes text && git commit -m 'Initial commit'
    [master (root-commit) 9a18d39] Initial commit
     2 files changed, 2 insertions(+)
     create mode 100644 .gitattributes
     create mode 100644 text

    $ echo 'crlf-terminated line' | unix2dos >text

    $ git add text  # Single CRLF warning as expected
    warning: CRLF will be replaced by LF in text.
    The file will have its original line endings in your working directory.

    $ git commit -m 'CRLF'  # Should have one CRLF warning, actually get two
    warning: CRLF will be replaced by LF in text.
    The file will have its original line endings in your working directory.
    [master 4a8b1cb] CRLF
    warning: CRLF will be replaced by LF in text.
    The file will have its original line endings in your working directory.
     1 file changed, 1 insertion(+), 1 deletion(-)

(Tangentially: what's the accepted practice for submitting failing test scripts? I've written a short test case to add to t0020 that shows this bugged behaviour, but I've got the vague impression from past emails that leading with the patch email adding the failing test case is not the expected way to do things on this list...)

Cheers,

Adam