Recommendation

As we are a cross-platform project, it is important that line-endings are handled consistently. Please abide by the general github advice: http://help.github.com/dealing-with-lineendings/

Mac & Linux

As the page says, Mac and Linux users do not get to sit this out, and should also configure their git repo to commit Unix-style line endings.

Windows msysgit

If you are using msysgit, you may be presented with these options:

Option two ('Checkout as-is, commit Unix-style line endings') should be used.

Having Problems - Used the Wrong Setting?

A recent checkout of both the SCAPE Tika repository and the Apache Tika repository would not successfully pass all unit tests.  In particular, asserting the mime-type of the testARofText.ar file (see testArchiveDetection(): TestMimeTypes.java: Line283) failed (mime-type returned as "text/plain" not "application/x-archive").  A hex-editor comparison of this file against the same file checked out on a freshly installed laptop showed a difference in line endings for this particular test file (testARofText.ar), suggesting a git line-ending configuration error.

Solution

Detailed look at the git configuration showed that one particular setting, core.autocrlf, differed between set-ups, with the problematic PC having two different values set:

The core.autocrlf setting tells git to convert newlines to the system's standard when checking out files, and to LF newlines when committing back [http://help.github.com/line-endings/].  This is the default behaviour when set to true; when set to input, line endings are always LF.  With both set, it seems the system settings override the global ones.

The solution is to only set a single core.autocrlf (either in system or global), in this case I opted to remove the system entry:

The files can manually be edited also, and can be found in the following locations:

• system: %PROGRAM FILES%/Git/etc/gitconfig
• global:   ~/.gitconfig