> 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
> Since the issue ended up being a bad regex in the build task, do you
> still want me to exclude adoc files specifically from gitattributes
> Dawid? I'll make the change if there's some particular reason why
> adoc files should be exempted here. But at a glance it seems like
> gitattributes
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? But if you leave it as «don’t
touch» such a mistake may happen, which was the root cause triggered
.gitattributes in the first place? Or do you mean that it now creates
> It's because of the recent change to solr/.gitattributes
> (SOLR-10713) [sic - SOLR-14186] End of lines differ for adoc files. Jason --
> please
> change this one from auto to "don't touch line endings on any of other
> files", whatever the magic is.
Since the issue ended up being a bad regex
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
> I also think its confusing to have gitattributes at the root and then also
> under solr/
Oh, that's new. There wasn't a root gitattributes when I wrote the
solr/ one. Must have been added around the same time through the
gradle work?
Anyway, there's no technical reason afaik to keep the
> It created an issue for me in that I spent two hours looking for a bug in the
> wrong place...
I regret that it made it harder for you to find the issue. But at the
end of the day the issue wasn't with gitattributes, it was a slip-up
in custom precommit code.
I agree with Jan - "auto"
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
> 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
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
Not annotating, but here are the failures in each of the last 4 weeks:
Failures in the last 4 reports..
Report Pct runsfails test
0123 0.3 1427 8 AutoScalingHandlerTest.testReadApi
0123 6.2 1495 66 BasicDistributedZkTest.test
11 matches
Mail list logo
