Adam Dinwoodie <a...@dinwoodie.org> writes: > 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.
Torsten, I know you are not heavily invested in "commit" codepath, but since you've been actively touching the CRLF area, I wonder perhaps you might be interested in taking a look? > > 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 -- 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
