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
> 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 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
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
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
> 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"
> 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
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
> 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
> 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
Sent: Sunday, January 26, 2020 11:46 AM
To: dev@lucene.apache.org
Subject: Re: analytics.adoc validation does not pass
Looking into.
On Sun, Jan 26, 2020 at 12:56 PM Dawid Weiss < <mailto:dawid.we...@gmail.com>
dawid.we...@gmail.com> wrote:
Hi Cassandra!
I get this when runni
Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Dawid Weiss
> Sent: Sunday, January 26, 2020 11:35 AM
> To: Uwe Schindler
> Cc: gerlowsk...@gmail.com; Lucene Dev ; Cassandra
> Targett ; md...@apache.org
> Subject: Re: analytics.adoc val
Looking into.
On Sun, Jan 26, 2020 at 12:56 PM Dawid Weiss wrote:
> Hi Cassandra!
>
> I get this when running precommit on gradle build (gradlew precommit):
>
> > Task :validateSourcePatterns
> [ant:groovy] Unescaped symbol "->" on line #43:
> solr/solr-ref-guide/src/analytics.adoc
>
Maybe. But I truly hate when git tries to alter those line endings for
me... this hasn't been the first time I spent an hour looking at what
the hell is wrong between Windows/ Linux on the same checkout...
D.
On Sun, Jan 26, 2020 at 11:34 AM Uwe Schindler wrote:
>
> But we should nevertheless
But we should nevertheless change the validator script to not fail on that. I
think the split by lines regex is problematic.
Uwe
Am January 26, 2020 10:31:11 AM UTC schrieb Dawid Weiss :
>Sigh... It's because of the recent change to solr/.gitattributes
>(SOLR-10713)... End of lines differ for
Sigh... It's because of the recent change to solr/.gitattributes
(SOLR-10713)... 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.
# Handles all files not treated particularly below
*
On Jenkins (Ant build) it only seems to happen on Windows. Which is strange.
Uwe
Am January 26, 2020 10:13:44 AM UTC schrieb Dawid Weiss :
>Ok, I think it's the validation code at fault here. Mike -- would you
>take a look at why the validation of solr-ref-guide doesn't pass?
>There has to be a
Ok, I think it's the validation code at fault here. Mike -- would you
take a look at why the validation of solr-ref-guide doesn't pass?
There has to be a difference in infrastructure somewhere because we
use the same validation script...
Dawid
On Sun, Jan 26, 2020 at 10:55 AM Dawid Weiss wrote:
18 matches
Mail list logo
