I opened https://issues.apache.org/jira/browse/LUCENE-9180
I don't mind doing the cleanup work once, but I'd like us to prevent new files with inconsistent newlines from being introduced in the future, because I don't want to do it again. I don't care how that is accomplished. It doesn't have to be "auto". On Mon, Jan 27, 2020 at 10:51 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > > 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 > >
