Git for Windows and line endings

Hi.. it is such a crime to have that default option of MSysGit mess around with the line endings.

Caused us a lot of trouble.

There is no thought to the fact that it's possible the Git users are not using Git the exact way the authors thought it would be used. We have both Windows and Linux systems that have parts of their files stored in Git repositories. And in addition to that, some Linux and Windows Git clients. If everyone leaves the line endings alone, everything works out just fine!

But messing with the line endings broke some things in production.

On Fri, Oct 19, 2012 at 12:13 AM, Chris B <chris.blaszczynski@gmail.com> wrote:

No it's not.

Suggesting this is just insulting. A lot of thought was laid to ground for the decision.

No, it will not. Notepad, which is the default text editor on Windows, barfs on LF line-endings, and many vi installations does the same thing on Unix-systems bards on CRLF line-endings. And so does a huge amount of custom, less tested tools.

Thinking that "this works for me, so it must work for everyone" is exactly the reason why this whole situation is a big mess. You are only making it worse by not realizing the issues.

I'm not even sure what you're trying to say with this e-mail other than to blame us for your own problems. Stop making broken commits. Clean up after you when you did by accident. And for the love of God, stop blaming other people when you messed up.

Hi,

On Fri, 19 Oct 2012, Erik Faye-Lund wrote:

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.

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.

Chris B <chris.blaszczynski@gmail.com> writes:

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:

Do you mean something like "git archive"? Or do you have something else in mind?

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.

On Fri, Oct 19, 2012 at 10:39:27AM -0400, Chris B wrote:

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.

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.

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

On Fri, Oct 19, 2012 at 10:39 AM, Chris B <chris.blaszczynski@gmail.com> wrote: [snip]

That's simply not a true, across the board statement. I really wish it was, because I find the issue troublesome as well. Unfortunately, there are still plenty of applications that don't cope with mixed line endings very well. We have a backend that targets several platforms, and the Windows toolchain is quite keen on having CRLF endings, but we like LF under Linux, and others.

I also wish that no developers were using Notepad either. Any time I've run across it, I've tried to point folks at much more capable environments... but that only has moderate success. Of course, it's even worse these days because Notepad puts a BOM at the front of the file, making Git think it's a binary file.

One thing I do wish is that I didn't have to do the song and dance to convert all the files when I set gitattributes:

    $ echo "* text=auto" >>.gitattributes
    $ rm .git/index     # Remove the index to force git to
    $ git reset         # re-scan the working directory
    $ git status        # Show files that will be normalized
    $ git add -u
    $ git add .gitattributes
    $ git commit -m "Introduce end-of-line normalization"

One thing that I like about Subversion was that when you set svn:eol-style, it took.

-John

Hi,

Chris B <chris.blaszczynski@gmail.com> writes: [snip]

There are several subtleties in LF handling with mixed systems. Here's my write-up in:

  https://github.com/mono/mono/blob/master/.gitattributes

for an example set of trade-offs.  Quoting in full since it's fairly short.

- Hari

# CRLF Handling # ------------- # # The ideal situation would be to do no EOL normalization. Each file # would have a default EOL, and tools on Windows and Linux would handle # both EOL formats. # # We're not in the ideal world. A popular editor on Windows (possibly # Visual Studio) silently introduces EOL corruption -- it displays an # LF-file normally, but any newly added lines have CRLF. On Linux, # Emacs and versions of VI handle LF-files and CRLF-files properly. # However, emacs doesn't like files with both LF and CRLF EOLs. Editing # the file without additional action will increase the EOL corruption # in the file. # # Another vector for mixed EOLs is scripts. We mostly don't have scripts # that add new lines -- so we rarely see this. However, one major event # in the tree was the addition of copyright headers using a script. That # script introduced EOL corruption. # # Any automated EOL normalization of files already in the repository will # cause difficulties in traversing histories, assigning blame, etc. So, we # don't want to change what's in the repository significantly, even if it # causes trouble. # # What we do now: # # a) we ensure that there's no further corruption of LF-files. So, we use # git's 'crlf' attribute on those files to ensure that things are fine # when we work on Windows. We could use 'crlf=input', but it doesn't buy # us much -- we might as well be working with consistent EOLs for files in # working directories as well as in the repository # # b) if the file already of CRLFs, we don't do any normalization. We use '-crlf' # so that git doesn't do any EOL-conversion of the file. As I said, this # is mostly harmless on Linux. We can't mark these files as 'crlf' or use # the new (git 1.7.2) 'eol=crlf' attribute, since it changes the contents # _inside_ the repository [1], and hence makes history traversal annoying. # So, we live with occasional EOL corruption. # # c) We can handle mixed-EOL files on a case-by-case basis, converting them to # LF- or CRLF-files based on which causes fewer lines to change # # d) We try to ensure no further headaches, by declaring EOL normalization on # code files, and Unix-flavoured files, like shell-scripts, makefiles, etc. # # [1] GIT use LFs as the normalized internal representation.