> I agree with Jan - "auto" prevents CRLF from being injected into the > files that don't need it, it's a Good Thing.
First of all, this isn't a personal attack, Jason. It's a personal sore wound caused by gitattributes that hurts every time I happen to come across it. > Now, if gitattributes breaks your normal workflow in some way - if your diffs > start looking > noisy and weird locally, if Eclipse or IntelliJ behave weirdly, if > builds fail, etc. - then absolutely we need to scale back what > gitattributes affects. This is exactly what should have happened and didn't. git diff wouldn't show any local changes on those files that had altered newlines compared to repository version (\r\n from repository's \n). I really like to keep the ability for git diff to show those differences (you can always run git diff -w if you don't care about white space). > If you feel strongly enough, I'll scale back what gitattributes > affects. But as Jan pointed out, this is a concrete benefit to us, Here are the problems I've had in the past if you're curious: 1) any checksum computation, length-dependence or something like this computed at build-time would compute different values on Windows vs. Linux leading to different archives being created, different file signatures, etc. 2) sometimes extension collisions do happen, especially on esoteric projects which store binaries. So a ".cmd" or a ".bat" can be a file that is not a Windows batch file... When git converts newlines upon commit not only it ended up messing up those files locally but also in the repository (if they were binary). 3) when you work on Windows and have global gitattributes things get even more weird but I don't want to go into that. > I noticed lots of ^Ms in the gradle files for example (I'm really not trying > to put > blame on anyone, just explain what I see) ...and they should be cleaned up! Let me be honest -- I personally remove .gitattributes from any repository. I've had enough problems with those conversions to just avoid them anywhere I can, especially globs. I don't mind if you guys feel like it's something really needed and helpful (which I don't quite agree with) but at least let's avoid auto globs for files not explicitly named. bq. Must have been added around the same time through the gradle work? Correct. This particular one holds lfs for versions lock which is generated and line endings differ depending on which system you use for updating (sigh). It is explicit though; not even a file extension: # Ignore all differences in line endings for the lock file. versions.lock text eol=lf Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
