Alex Riesen said the following on 25.07.2007 01:15:
Marius Storm-Olsen, Tue, Jul 24, 2007 21:36:06 +0200:IMO Windows user expect files to be DOS style, since all other files are. Yes, most newer tools 'handle' Unix style files, but creating new ones will mostly be DOS style. Some will actually wreak havoc on your files, and start adding DOS line endings in the middle of your Unix line ending file. I've seen it happen. So, dealing with Unix style text files on Windows can be a problem for some people.I have to stay with Windows, but I'd absolute hate having their stupid line-ending by default. As will my project supervisor, and he gets changes from something like 300 developers. You will definitely get their votes against changing the default
Ok, so maybe not changing the default.Though it's weird behavior for _most_ Windows developers out there, I agree that the current Windows Git population would mostly prefer the Unix line endings. And I can see how someone who's working on Windows and handling a lot of patches from other developers of multiple OSs also wanting the non-platform-standard Unix line-endings. I still would argue that it's not the norm. Currently yes, in the foreseeable future, I doubt it.
Git is really slowed down tremendously just by the fact that it runs on Windows. You should not add to that.The auto crlf conversion is not the slow down here, and the time spent there is negligible. I use autocrlf on all my repos on Windows, and don't notice it. Filestat'ing on the other hand.. :-)Of course you wont notice it: you're already on Windows.
Come on, when did a search and replace in a normal size source file take any time? It's really not an argument for not doing CRLF conversion on a platform that creates CRLF files by default!
If you want files to be stored in the repo with Unix line-endings, which I expect most people would want, to share it with other non-Windows developers, you _have_ to do it. (No, not the MSys/Cygwin users)
IMHO in most cases -- even on Windows -- you do not want to set autocrlf at all. Because you do not need to store the file different from the version you have in the working tree.Not true. I believe, especially at the moment, most Git users on Windows are mostly developing code in a cross-platform manner, and therefore care about this problem.Yes. They solve it by working fulltime in \n-lineending. Avoiding that stupid Visual Studio and Notepad helps too.
Huh? You just removed more than 3 _million_[1] potential users.. (Some say 8 million [2]) Is that a good argument? Why should developers on Windows avoid using Windows tools? Because they're 'idiots'? (ref further down in your reply)
Anyways, even if a tool on Windows _handles_ LF line-endings perfectly fine, most of these tools still create CR/LF files when you create a new text file. (No, again not the MSys or LF-configured Cygwin vim/emacs/<insert your favorite unix editor here>. But the native editors which handles both formats. There's plenty of those too.)
The only situation where I think it makes sense, is when you have both Windows and Unix developers, _and_ your Windows tools sometimes produce CR/LF stupidly. But then I'd set it to "input".That's ok _now_, because most of the Git user group is experienced developer that understand the problem. I'm trying to see past that state, and prepare Git for more 'common' usage on Windows. They'd expect text files on Windows to be handled correctly, without any fuzz.Just make the windows installer to setup templates for CR/LF depending on checkbox "[ ] I am Windows idiot, standard issue".
Mmm, ok. If I'm an idiot just for using Windows, I guess the battle is lost already.
No tweaking of config options to make it work on Windows. No problems with sharing repositories with Unix developers. Just work. That's not the current state. But it could be.It is for me. It will not be that with your suggested default.
Then I wouldn't put you in the normal Windows developer category, but rather the one which is dependent on MSys or Cygwin, and live in bash/zsh on Windows. I would argue that most of those 3/8 million VS users are not in the same category as you.
But sure, I don't mind having to set core.autocrlf=true when I configure Git, but then I would like that mode to work without the extra hassle. (Most people don't want to change already incorporated options, which is fully understandable)
Ok, I come from the Perforce world, so here how it works there: 1) Files are stored with Unix line endings in the repository. 2) Conversion is done on Windows (and older Macs) upon checkout, if the file is a text file. 3) It has binary file detection when you add it to the depot, so if you and to add a DOS line ending file to the repo, you have to mark it as a binary file manuallyYou always setup the lineending conversion in perforce. For each and every client. There is no default. I just don't see what to learn from them (if there ever was something to learn from).
No you don't. You _can_, but the default when you create a 'client spec' is the platform specific line endings. Only 'Unix' users working on Windows really take the trouble of changing the line endings to they work with their MSys or Cygwin enviroments.
... And Git would probably be adapted on Windows more quickly, which this is all about. :-) IMHO.It is hardly worth it. Git already has to put up with ugly workarounds just because of the stupidities coming from that windows. It has had seldom any benefit from supporting this !@#$ing awkward platform.
Well, I guess with this opinion there really no point in me trying to prove a point. If all Windows users are 'idiots' on a '!@#$ing awkward' platform, I'm probably just an 'idiot' trying to help out.
I hope it's not the general opinion of the Git team that Windows users should just bugger off..
Now, personally I don't have a problem with all this line ending stuff. I work on Windows and Unix on a daily basis, addicted to MSys and Cygwin for performing my daily tasks, and use tools which handles LF and CR/LF interchangeably without any problems. So, the current state of Git works for me. I'm just trying to help figuring out what we can do to make the tool even more platform agnostic, and work as expected.
[1] http://msdn.microsoft.com/vsip [2] http://www.regdeveloper.co.uk/2007/06/09/vs_shell_eclipse/ -- .marius
Attachment:
signature.asc
Description: OpenPGP digital signature
