Apache Nutch源码工程在Linux和Windows平台换行符差异问题处理
最近在提交发布个人开源项目：https://github.com/xautlx/nutch-ajax （基于Apache Nutch 2.3和Htmlunit, Selenium WebDriver等组件扩展，实现对于AJAX加载类型页面的完整页面内容抓取，以及特定数据项的解析和索引）时遇到一个问题：
开源项目提交时为了便于跟踪变更记录，首先GIT初始化提交了从Apache下载获取的Apache Nutch 2.3源码，然后在此基础上添加扩展插件代码准备提交时在资源库同步视图显示所有代码都需要更新，后来开启Eclipse的显示不可见视图才发现有个“carriage return”差异，问题根源在Windows平台和Unix/Linux平台对于回车换行的处理差异导致的。Apache官方提供的源码应该是基于Linux平台的，放到Windows平台做了一些拷贝迁移之后出现了字符差异。
最后网上搜索相关资料得到如下解决方案：
git客户端添加参数core.autocrlf=true
然后再次重新check out或reset服务器linux格式代码，再在此基础上变更后再提交就只会涉及实际变更的文件列表了。
参考资料：
http://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration
Formatting and Whitespace
Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. It’s very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them, and if your files ever touch a Windows system, their line endings might be replaced. Git has a few configuration options to help with these issues.
core.autocrlf
If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.
Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:
$ git config –global core.autocrlf true
If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:
$ git config –global core.autocrlf input
This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.
If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false:
$ git config –global core.autocrlf false
core.whitespace
Git comes preset to detect and fix some whitespace issues. It can look for six primary whitespace issues – three are enabled by default and can be turned off, and three are disabled by default but can be activated.
The ones that are turned on by default are blank-at-eol, which looks for spaces at the end of a line; blank-at-eof, which notices blank lines at the end of a file; and space-before-tab, which looks for spaces before tabs at the beginning of a line.
The three that are disabled by default but can be turned on are indent-with-non-tab, which looks for lines that begin with spaces instead of tabs (and is controlled by the tabwidth option); tab-in-indent, which watches for tabs in the indentation portion of a line; and cr-at-eol, which tells Git that carriage returns at the end of lines are OK.
You can tell Git which of these you want enabled by setting core.whitespace to the values you want on or off, separated by commas. You can disable settings by either leaving them out of the setting string or prepending a - in front of the value. For example, if you want all but cr-at-eol to be set, you can do this:
$ git config –global core.whitespace \
trailing-space,space-before-tab,indent-with-non-tab
Git will detect these issues when you run a git diff command and try to color them so you can possibly fix them before you commit. It will also use these values to help you when you apply patches with git apply. When you’re applying patches, you can ask Git to warn you if it’s applying patches with the specified whitespace issues:
$ git apply –whitespace=warn
Or you can have Git try to automatically fix the issue before applying the patch:
$ git apply –whitespace=fix
These options apply to the git rebase command as well. If you’ve committed whitespace issues but haven’t yet pushed upstream, you can run git rebase –whitespace=fix to have Git automatically fix whitespace issues as it’s rewriting the patches.