Bug report: Duplicate CRLF rewrite warnings on commit

[Adam Dinwoodie <adam@dinwoodie.org>]

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