Hi,
I agree with Dawid. By default e.g. Jenkins Slave and also TortoiseGit on
Windows don't set windows file endings by default. You have to enable it in the
config or the installation program.
Currently the Lucene build system has some SVN relics in it. If you recreate
the autogenerated
> Lots of people on Windows use programs like Notepad for "serious" work.
This is not an argument for me. Using broken tools is not an excuse. There
are many excellent text editors for Windows (in fact, I haven't been
able to find an editor
seriously competing with EmEditor in either Linux or
On 3/2/2018 1:58 PM, Dawid Weiss wrote:
> I typically set my windows git to NOT alter anything with regard to
> line endings. (checkout as-is, commit as-is).
> This really helps in avoiding weird errors.
When using sane tools that deal with line ending discrepancies properly,
this is a perfectly
I typically set my windows git to NOT alter anything with regard to
line endings. (checkout as-is, commit as-is).
This really helps in avoiding weird errors.
Dawid
On Fri, Mar 2, 2018 at 9:43 PM, Shawn Heisey wrote:
> On 3/2/2018 12:57 PM, Uwe Schindler wrote:
>> This
On 3/2/2018 12:57 PM, Uwe Schindler wrote:
> This change would break my checkout' because my git is configured for
> Linux line endings. So the crlf fix is needed.
>
> Windows Jenkins on ist also using Linux line endings.
>
> IMHO we should do it like in svn: mark those files as binary. Not sure
This change would break my checkout' because my git is configured for Linux
line endings. So the crlf fix is needed.
Windows Jenkins on ist also using Linux line endings.
IMHO we should do it like in svn: mark those files as binary. Not sure how.
BTW. The same issue appears with other
I notice that when "ant jar-checksums" is run on Windows, it modifies
every single hash file for dependent jars. The actual hashes aren't
modified unless a dependency has changed, but the line endings are.
I get lots of lines similar to these (on stderr) if I do "git diff"
after the ant action: