Hi. I'm sorry about the tone of the email; I was writing it after spending a lot of energy fixing things up and I should have taken some time to breathe. I recognize this is likely not going to change and even if I could jump in to contribute it wouldn't matter. I also recognize that changing it now might cause more problems. I am hopeful though. I would like to point out: - Git on Linux does not mess around with line endings. I can create and edit a file in either line ending on Linux and commit and still have it untouched. - Git on Windows via Cygwin also does not mess around. - If those flavors of Git don't mess around, why should msysgit do it? - Windows has been able to cope with UNIX line endings a long time; no developer is using a default Notepad to open files with high expectations. Any Windows development tool and editor worth anything I've used is able to handle both just fine. - VIM also handles Windows line endings just fine as well. I just tested it on a Linux machine. Maybe old version? (pure VI is not even on this machine but hard to press these days it can't handle it.) - The files in .git folder are in UNIX format anyway, so why are those not also included in line ending changes? Isn't is because there is a Windows app (msysgit) running on Windows that expects the UNIX line ending? So in the same manor, someone might have a Windows system using some Cygwin components perhaps, or a Windows C program possibly poorly written or just old, that demand some text files to be left alone in the format we saved it. - If there was SO MUCH thought into this, then it was too much; it was the wrong thought. There should not have been much at all, and just allow Git to do what it does: store things *exactly* as you put it in. Allow the clients to worry about things like line endings should they have the need to worry about it. I'm not seeing how the revision system has any business making alterations to things one commits into it. - Our builds were not breaking, it was production due to deployment model utilizing Git. What if there was a process to extract from Git and then distribute? Sounds like it's simple and should work and there are good advantages to this process to overcome speed of deployment issues. That process is free to be either Linux or Windows, and to distribute to either a Linux or Windows server. This process you may consider a mistake, but the point is that Git is just storing things, not worried about the process in which it is used. - While there might be options to make the other flavors of Git mess around with line endings, the default is to not touch it which is critical. Because as you bring on developers you never know what they selected during the installation, and you have to go back and have them change it if they did something different. - Developers are not expecting revision control system to make changes to files they commit. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html