summaryrefslogtreecommitdiff
path: root/_posts/2008-04-05-line-endings.textile
diff options
context:
space:
mode:
authorCameron McEfee <cameron@github.com>2011-06-06 18:43:16 -0700
committerCameron McEfee <cameron@github.com>2011-06-06 18:43:16 -0700
commit68b2217289711a4b78c0476b404b351afbbe655f (patch)
tree7aa27243949667d1c12ee6518eb8063d83d11c97 /_posts/2008-04-05-line-endings.textile
parent3f78d29f08fda99eda887aad14f99baf1c71636e (diff)
parent7edd04eeaa188cf0e87dfc71b2278785dcdf7ed6 (diff)
Merge pull request #30 from github/reorder-nav
Reorder nav, reduce each post to one category, rename for usability
Diffstat (limited to '_posts/2008-04-05-line-endings.textile')
-rw-r--r--_posts/2008-04-05-line-endings.textile50
1 files changed, 50 insertions, 0 deletions
diff --git a/_posts/2008-04-05-line-endings.textile b/_posts/2008-04-05-line-endings.textile
new file mode 100644
index 0000000..3a51f09
--- /dev/null
+++ b/_posts/2008-04-05-line-endings.textile
@@ -0,0 +1,50 @@
+---
+layout: default
+title: Line endings
+description: How to ensure that line endings are consistent in your repo
+categories: troubleshooting
+---
+
+<p class="intro">Line endings... the scourge of every Windows-based developer that tries to mingle with linux- or mac-based developers. Though most modern text editors can handle both newline types without issue, git is not as graceful.</p>
+
+<p class="intro">For more info on the issue see "Wikipedia":http://en.wikipedia.org/wiki/Newline.</p>
+
+h2. Mac and Linux users, you don't get to sit this one out
+
+Although you might think you're immune to CRLF-ended files on mac and linux, you are not. It is possible to download files from an external source that use CRLF, and thus commit them into your repo. To be safe, you should set your config to convert line endings on commit so they are always LF in the repo:
+
+<pre class="terminal">$ git config --global core.autocrlf input</pre>
+
+h2. I just cloned and git says files have changed!
+
+So, you just cloned a repo on a Windows box, and it says that all of your files have been modified. Huh? You've not touched anything yet! What the...
+
+The problem is that your @core.autocrlf@ option is likely not enabled. This setting tells git to convert the newlines to the system's standard when checking out files, and to LF newlines when committing in. To turn it on use this command:
+
+<pre class="terminal">$ git config --global core.autocrlf true</pre>
+
+Once this is set, you need to reset your repos. The best way to do this is wipe out your working tree (all the files except the .git directory) and then restore them:
+
+<pre class="terminal"># Remove everything from the index
+$ git rm --cached -r .
+
+# Re-add all the deleted files to the index
+# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
+$ git diff --cached --name-only -z | xargs -0 git add
+
+# Commit
+$ git commit -m "Fix CRLF"
+
+# If you're doing this on a Unix/Mac OSX clone then optionally remove
+# the working tree and re-check everything out with the correct line endings.
+$ git ls-files -z | xargs -0 rm
+$ git checkout .
+</pre>
+
+p(. _Thanks to Charles Bailey's post on "stack<b>overflow</b>":http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-git-filter-branch-but-having-no-luck/1511273#1511273 for this solution._
+
+h2. Moving forward
+
+Now that you've standardized the newlines in your repo things should be better. However, every person that touches your repo should turn autocrlf on, even non-Windows users. It is possible for them to bring in code from an outside source that has CRLF newlines, and you don't want them saved into the repo like that.
+
+For more details on the @core.autocrlf@ setting see the "git-config documentation":http://www.kernel.org/pub/software/scm/git/docs/git-config.html.