Re: [msysGit] Re: Git for Windows and line endings
Hi, On Fri, 19 Oct 2012, Erik Faye-Lund wrote: On Fri, Oct 19, 2012 at 12:13 AM, Chris B chris.blaszczyn...@gmail.com wrote: Hi.. it is such a crime to have that default option of MSysGit mess around with the line endings. No it's not. Let's keep things professional. Eliciting emotions, especially negative ones, traditionally makes it more unlikely to get what one asks for. Also to clarify: as so many Open Source projects (but unlike Git itself), msysGit is a purely volunteer-driven software. So naturally, contributors have a lot more to say about the defaults than non-contributors [*1*]. Besides, there is a fantastic and very detailed page when running the installer where the interested user can inform herself and change the defaults to her likings very easily. Therefore I consider this bug report -- insofar it was one -- as closed. Ciao, Johannes Footnote [*1*]: And yes, the line endings default was changed from this developer's preference to what it is now -- based on a discussion with convincing arguments. Since msysGit is developed as an Open Source project with a truly Open Source process, all of these discussions can be found in the mailing list archives. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Git for Windows and line endings
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Git for Windows and line endings
Chris B chris.blaszczyn...@gmail.com writes: - If there was SO MUCH thought into this, then it was too much... I do not have much to add to what area experts already said on bits specific to Git for Windows, but on just this part: - 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? Do you mean something like git archive? Or do you have something else in mind? - Developers are not expecting revision control system to make changes to files they commit. But isn't there a distinction between the logical content and its physical representation? In source code (that is what developers use a source code management system for), especially those of cross-platform projects, the logical lines end with LF and physical lines end with whatever is convenient on the platform of each participant of the project. There needs a way to convert between the two. It does not sound fair to call it a crime if the port to a platform, whose users (at least the majority of them) expect the latter to be CRLF, chose to default to that to help the majority, as long as there are ways for the minority power users to choose to use LF in the physical representation on their working trees. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Git for Windows and line endings
On Fri, Oct 19, 2012 at 10:39:27AM -0400, Chris B wrote: 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? Most platforms (i.e., the userspace of most unix-y distributions) do not mess around with line endings, either, so it is easy to have a sane default there. I think the Cygwin build just followed that existing defaults. But msysgit's behavior was directly responding to user complaints. And there were a lot of them. I do not use Windows myself, so I have only the perspective of reading the list discussions. And that only what bleeds onto the git@vger list, not the msysgit list. Searching for crlf on the list yields over 2300 messages, many of which discuss specific problems people are having without CRLF support. I do not think any decision in the open source world is final, and correcting a wrong decision from the past should always be an option. But I do not think it is constructive to say your decision is wrong without responding to the arguments that led to that decision. All I see in your email is your default is not my preference without responding to the discussion and perspectives of others through the years. - 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. Again, I do not use Windows, so my anecdotes are purely culled from the list. But people have mentioned that Visual Studio is bad for writing our CRLFs for files which already have LFs. This makes diffs unreadable, and gives merges, rebases and cherry-picks lots of spurious conflicts. - 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. One of the problems is that people do not realize the issue until they have built a lot of history with CRLFs or mixed line endings (which they might not even realize until the project starts being used by somebody with a different editor or platform), and then they have a very painful flag day turning on these options and normalizing the repository. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
