Here is a list of all non-binary files in master with DOS endings: $ git grep -I -l '^M' .gitattributes dev-tools/git/HELP.txt gradle/help.gradle gradle/testing/failed-tests-at-end.gradle gradle/testing/per-project-summary.gradle gradle/testing/runtime-jvm-support.gradle gradle/testing/slowest-tests-at-end.gradle gradle/validation/check-environment.gradle gradle/validation/forbidden-apis.gradle gradle/validation/git-status.gradle gradle/validation/jar-checks.gradle gradle/validation/precommit.gradle gradlew.bat help/dependencies.txt help/git.txt help/tests.txt lucene/licenses/hamcrest-core-LICENSE-BSD.txt solr/bin/solr.cmd solr/bin/solr.in.cmd solr/licenses/hamcrest-core-LICENSE-BSD.txt solr/server/scripts/cloud-scripts/zkcli.bat solr/solr-ref-guide/src/fonts/Inconsolata/OFL.txt
On Mon, Jan 27, 2020 at 10:08 AM Robert Muir <rcm...@gmail.com> wrote: > There does seem to be a bit of a mess here. 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) > > I don't complain about it, my vim setup detects the file as DOS and then > just continues with the trend, but for sure its strange to have some source > files with DOS line endings and other ones with UNIX line endings, > depending on who created the files. I see it when reviewing my stuff with > 'git diff'... > > For example: > gradle/testing/defaults-tests.gradle: UNIX line endings > gradle/testing/failed-tests-at-end.gradle: DOS line endings > > I also think its confusing to have gitattributes at the root and then also > under solr/ > can we just have one gitattributes file at the root? > > There shouldn't be that many files that require explicit line endings > settings (e.g. .cmd files come to mind). > > On Mon, Jan 27, 2020 at 7:48 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > >> > auto for .adoc files will guard us from a Windows user checking in an >> .adoc file with CRLF ending in the future, won’t it? >> >> The current rule applies to all files not explicitly listed -- I think >> this is wrong. You can add adoc explicitly but don't apply it to the >> world at large... >> >> > Or do you mean that it now creates issues for Windows users in some way? >> >> It created an issue for me in that I spent two hours looking for a bug >> in the wrong place... and the same problems with auto-magical git >> conversions happen *over and over* for me in multiple projects -- it's >> not the first time. >> >> It is really hard to figure out what's going on when you stumble upon >> a problem like this. Also, like I said previously, I don't trust all >> git implementations and versions to handle those directives >> identically (jgit in particular). I don't mind those rules as long as >> they create identical repository on local clone/reset. This means all >> hashes of all files should be identical: windows or linux. If they're >> not the same it's potentially trouble. >> >> If we're so concerned about CRLF then I'd say add such rules to >> precommit check (I can do it, no problem) but those automatic >> conversions are/will be a constant trouble. >> >> D. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
