Actually, CRLF isn't that big of an issue if everyone has their settings correct (yes, that's a big if). On windows it should be true, which is what msysgit sets on install unless you change it. On linux and OSX, though, it's usually set to false, which is incorrect. If it's not set to input, OSX and linux users can introduce a CRLF'd files unintentionally. No, it won't happen if the file was generated on that OS directly, but external files (downloaded libraries!) might have them. True and input are the way to go.
For more info on how to fix the CRLF issues see: http://help.github.com/dealing-with-lineendings Avery, it sounds like you have a direct line to the git devs, my suggestion is that git automatically use true on windows and input on everything else unless the user specifically overrides the autocrlf setting. Right now it defaults to false if it isn't set. It's very rare for the line endings to truly matter (i.e. a windows program imploding if it receives LF, like, say, notepad)... so it's probably best to use smart defaults and let the user disable it if it's a problem on a case by case basis. On Mon, Feb 14, 2011 at 1:12 AM, Avery Pennarun <apenw...@gmail.com> wrote: > On Sun, Feb 13, 2011 at 9:21 PM, jd <chima...@gmail.com> wrote: > > On Feb 13, 8:52 pm, Abhishek Shadangi <shada...@gmail.com> wrote: > >> That's because - git checkout will checkout the files from the git > >> database, and will use your CRLF settings native to you OS and modify > the > >> files. > > > > Ok, so I turned off autocrlf and now 'git status' says that nothing > > has changed. > > > > I'm still somewhat puzzled. I can see that with autocrlf turned on, > > some of my files > > might have undergone CRLF-ification. But if so, shouldn't git > > recognize that the > > CRLFs were added (and would presumably be removed on commit)? > > > > Also, some of my files already had consistent usage of CRLF; why would > > those files > > be affected by autocrlf? > > > > Thanks for your continued help on this issue. I'd like to gain a good > > enough > > understanding so that I don't shoot myself in the foot again ;-) > > Basically git's autocrlf setting is buggy and always has been. You > can sometimes munge it into working if you set it *before* checking > out of a repo, but if you set it on an already-checked-out repo, weird > things generally happen. > > The git developers have put quite a bit of work into fixing it, but > unfortunately none of the core developers use Windows, thus none of > them have crlf problems. The developers who *do* have crlf problems > learned to set the setting once and ignore it. So the problems tend > not to get entirely fixed. > > I did see some patches go by; maybe a newer version of git will fix > the problem though. > > One common git crlf problem occurs when someone *not* using autocrlf > commits a file that contains crlf instead of lf line endings. Then > when you checkout the file with autocrlf enabled, git gets confused. > > The easiest thing to do is to just never use autocrlf mode; if all > your developers are on Windows anyway, you don't need to fix the crlf > problems anyhow. > > Have fun, > > Avery > > -- > You received this message because you are subscribed to the Google Groups > "GitHub" group. > To post to this group, send email to github@googlegroups.com. > To unsubscribe from this group, send email to > github+unsubscr...@googlegroups.com<github%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/github?hl=en. > > -- You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to github@googlegroups.com. To unsubscribe from this group, send email to github+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/github?hl=en.
