{"thread":{"id":"31861","subject":"Git for Windows and line endings","startedAt":"2012-10-18T22:13:07Z","lastAt":"2012-11-04T12:37:53Z","messageCount":8,"participants":["Chris B","Erik Faye-Lund","Johannes Schindelin","Junio C Hamano","Jeff King","John Szakmeister","Raja R Harinath"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"201532","messageId":"CADKp0pyy=Nnv29LyhzAOX4B5wJNYnZ0h5d7zxNRyZxV2OGUSjg@mail.gmail.com","threadId":"31861","inReplyTo":null,"subject":"Git for Windows and line endings","fromName":"Chris B","fromEmail":"chris.blaszczynski@gmail.com","sentAt":"2012-10-18T22:13:07Z","receivedAt":"2012-10-18T22:13:07Z","isPatch":false,"sender":{"key":"chris.blaszczynski@gmail.com","avatar":null},"body":"Hi.. it is such a crime to have that default option of MSysGit mess\naround with the line endings.\n\nCaused us a lot of trouble.\n\nThere is no thought to the fact that it's possible the Git users are\nnot using Git the exact way the authors thought it would be used.\nWe have both Windows and Linux systems that have parts of their files\nstored in Git repositories. And in addition to that, some Linux and\nWindows Git clients. If everyone leaves the line endings alone,\neverything works out just fine!\n\nBut messing with the line endings broke some things in production.\n"},{"id":"201533","messageId":"CABPQNSZE7TP0G-uW1b1nbsNgpxYCEiD5KefS62GB5gZbWyZXDQ@mail.gmail.com","threadId":"31861","inReplyTo":"CADKp0pyy=Nnv29LyhzAOX4B5wJNYnZ0h5d7zxNRyZxV2OGUSjg@mail.gmail.com","subject":"Re: Git for Windows and line endings","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-10-18T22:40:11Z","receivedAt":"2012-10-18T22:40:11Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Oct 19, 2012 at 12:13 AM, Chris B <chris.blaszczynski@gmail.com> wrote:\n> Hi.. it is such a crime to have that default option of MSysGit mess\n> around with the line endings.\n\nNo it's not.\n\n> There is no thought to the fact that it's possible the Git users are\n> not using Git the exact way the authors thought it would be used.\n\nSuggesting this is just insulting. A lot of thought was laid to ground\nfor the decision.\n\n> We have both Windows and Linux systems that have parts of their files\n> stored in Git repositories. And in addition to that, some Linux and\n> Windows Git clients. If everyone leaves the line endings alone,\n> everything works out just fine!\n\nNo, it will not. Notepad, which is the default text editor on Windows,\nbarfs on LF line-endings, and many vi installations does the same\nthing on Unix-systems bards on CRLF line-endings. And so does a huge\namount of custom, less tested tools.\n\nThinking that \"this works for me, so it must work for everyone\" is\nexactly the reason why this whole situation is a big mess. You are\nonly making it worse by not realizing the issues.\n\n> But messing with the line endings broke some things in production.\n\nI'm not even sure what you're trying to say with this e-mail other\nthan to blame us for your own problems. Stop making broken commits.\nClean up after you when you did by accident. And for the love of God,\nstop blaming other people when you messed up.\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"201547","messageId":"alpine.DEB.1.00.1210190801490.2695@bonsai2","threadId":"31861","inReplyTo":"CABPQNSZE7TP0G-uW1b1nbsNgpxYCEiD5KefS62GB5gZbWyZXDQ@mail.gmail.com","subject":"Re: Re: Git for Windows and line endings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2012-10-19T06:09:40Z","receivedAt":"2012-10-19T06:09:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Oct 2012, Erik Faye-Lund wrote:\n\n> On Fri, Oct 19, 2012 at 12:13 AM, Chris B <chris.blaszczynski@gmail.com> wrote:\n> > Hi.. it is such a crime to have that default option of MSysGit mess\n> > around with the line endings.\n> \n> No it's not.\n\nLet's keep things professional. Eliciting emotions, especially negative\nones, traditionally makes it more unlikely to get what one asks for.\n\nAlso to clarify: as so many Open Source projects (but unlike Git itself),\nmsysGit is a purely volunteer-driven software. So naturally, contributors\nhave a lot more to say about the defaults than non-contributors [*1*].\n\nBesides, there is a fantastic and very detailed page when running the\ninstaller where the interested user can inform herself and change the\ndefaults to her likings very easily.\n\nTherefore I consider this bug report -- insofar it was one -- as closed.\n\nCiao,\nJohannes\n\nFootnote [*1*]: And yes, the line endings default was changed from this\ndeveloper's preference to what it is now -- based on a discussion with\nconvincing arguments. Since msysGit is developed as an Open Source project\nwith a truly Open Source process, all of these discussions can be found in\nthe mailing list archives.\n\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"201556","messageId":"CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com","threadId":"31861","inReplyTo":"alpine.DEB.1.00.1210190801490.2695@bonsai2","subject":"Re: [msysGit] Re: Git for Windows and line endings","fromName":"Chris B","fromEmail":"chris.blaszczynski@gmail.com","sentAt":"2012-10-19T14:39:27Z","receivedAt":"2012-10-19T14:39:27Z","isPatch":false,"sender":{"key":"chris.blaszczynski@gmail.com","avatar":null},"body":"Hi.  I'm sorry about the tone of the email; I was writing it after\nspending a lot of energy fixing things up and I should have taken some\ntime to breathe. I recognize this is likely not going to change and\neven if I could jump in to contribute it wouldn't matter. I also\nrecognize that changing it now might cause more problems. I am hopeful\nthough.\n\nI would like to point out:\n- Git on Linux does not mess around with line endings. I can create\nand edit a file in either line ending on Linux and commit and still\nhave it untouched.\n- Git on Windows via Cygwin also does not mess around.\n- If those flavors of Git don't mess around, why should msysgit do it?\n\n- Windows has been able to cope with UNIX line endings a long time; no\ndeveloper is using a default Notepad to open files with high\nexpectations. Any Windows development tool and editor worth anything\nI've used is able to handle both just fine.\n- VIM also handles Windows line endings just fine as well. I just\ntested it on a Linux machine. Maybe old version? (pure VI is not even\non this machine but hard to press these days it can't handle it.)\n- The files in .git folder are in UNIX format anyway, so why are those\nnot also included in line ending changes? Isn't is because there is a\nWindows app (msysgit) running on Windows that expects the UNIX line\nending? So in the same manor, someone might have a Windows system\nusing some Cygwin components perhaps, or a Windows C program possibly\npoorly written or just old, that demand some text files to be left\nalone in the format we saved it.\n\n- If there was SO MUCH thought into this, then it was too much; it was\nthe wrong thought. There should not have been much at all, and just\nallow Git to do what it does: store things *exactly* as you put it in.\nAllow the clients to worry about things like line endings should they\nhave the need to worry about it. I'm not seeing how the revision\nsystem has any business making alterations to things one commits into\nit.\n\n- Our builds were not breaking, it was production due to deployment\nmodel utilizing Git. What if there was a process to extract from Git\nand then distribute? Sounds like it's simple and should work and there\nare good advantages to this process to overcome speed of deployment\nissues. That process is free to be either Linux or Windows, and to\ndistribute to either a Linux or Windows server. This process you may\nconsider a mistake, but the point is that Git is just storing things,\nnot worried about the process in which it is used.\n\n- While there might be options to make the other flavors of Git mess\naround with line endings, the default is to not touch it which is\ncritical. Because as you bring on developers you never know what they\nselected during the installation, and you have to go back and have\nthem change it if they did something different.\n\n- Developers are not expecting revision control system to make changes\nto files they commit.\n"},{"id":"201561","messageId":"7vlif2js1r.fsf@alter.siamese.dyndns.org","threadId":"31861","inReplyTo":"CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com","subject":"Re: Re: Git for Windows and line endings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-19T17:22:08Z","receivedAt":"2012-10-19T17:22:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris B <chris.blaszczynski@gmail.com> writes:\n\n> - If there was SO MUCH thought into this, then it was too much...\n\nI do not have much to add to what area experts already said on bits\nspecific to Git for Windows, but on just this part:\n\n> - Our builds were not breaking, it was production due to deployment\n> model utilizing Git. What if there was a process to extract from Git\n> and then distribute?\n\nDo you mean something like \"git archive\"?  Or do you have something\nelse in mind?\n\n> - Developers are not expecting revision control system to make changes\n> to files they commit.\n\nBut isn't there a distinction between the logical content and its\nphysical representation?  In source code (that is what developers\nuse a source code management system for), especially those of\ncross-platform projects, the logical lines end with LF and physical\nlines end with whatever is convenient on the platform of each\nparticipant of the project.  There needs a way to convert between\nthe two.\n\nIt does not sound fair to call it a crime if the port to a platform,\nwhose users (at least the majority of them) expect the latter to be\nCRLF, chose to default to that to help the majority, as long as\nthere are ways for the minority power users to choose to use LF in\nthe physical representation on their working trees.\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"201571","messageId":"20121019205933.GC24184@sigill.intra.peff.net","threadId":"31861","inReplyTo":"CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com","subject":"Re: Re: Git for Windows and line endings","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-19T20:59:33Z","receivedAt":"2012-10-19T20:59:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2012 at 10:39:27AM -0400, Chris B wrote:\n\n> I would like to point out:\n> - Git on Linux does not mess around with line endings. I can create\n> and edit a file in either line ending on Linux and commit and still\n> have it untouched.\n> - Git on Windows via Cygwin also does not mess around.\n> - If those flavors of Git don't mess around, why should msysgit do it?\n\nMost platforms (i.e., the userspace of most unix-y distributions) do not\nmess around with line endings, either, so it is easy to have a sane\ndefault there. I think the Cygwin build just followed that existing\ndefaults.\n\nBut msysgit's behavior was directly responding to user complaints. And\nthere were a lot of them. I do not use Windows myself, so I have only\nthe perspective of reading the list discussions. And that only what\nbleeds onto the git@vger list, not the msysgit list.\n\nSearching for \"crlf\" on the list yields over 2300 messages, many of\nwhich discuss specific problems people are having without CRLF support.\nI do not think any decision in the open source world is final, and\ncorrecting a wrong decision from the past should always be an option.\nBut I do not think it is constructive to say \"your decision is wrong\"\nwithout responding to the arguments that led to that decision. All I see\nin your email is \"your default is not my preference\" without responding\nto the discussion and perspectives of others through the years.\n\n> - Windows has been able to cope with UNIX line endings a long time; no\n> developer is using a default Notepad to open files with high\n> expectations. Any Windows development tool and editor worth anything\n> I've used is able to handle both just fine.\n\nAgain, I do not use Windows, so my anecdotes are purely culled from the\nlist. But people have mentioned that Visual Studio is bad for writing\nour CRLFs for files which already have LFs. This makes diffs unreadable,\nand gives merges, rebases and cherry-picks lots of spurious conflicts.\n\n> - If there was SO MUCH thought into this, then it was too much; it was\n> the wrong thought. There should not have been much at all, and just\n> allow Git to do what it does: store things *exactly* as you put it in.\n> Allow the clients to worry about things like line endings should they\n> have the need to worry about it. I'm not seeing how the revision\n> system has any business making alterations to things one commits into\n> it.\n\nOne of the problems is that people do not realize the issue until they\nhave built a lot of history with CRLFs or mixed line endings (which they\nmight not even realize until the project starts being used by somebody\nwith a different editor or platform), and then they have a very painful\nflag day turning on these options and normalizing the repository.\n\n-Peff\n\n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n"},{"id":"201579","messageId":"CAEBDL5UX+bT5eSf4_QxfcOgwH0Vtco43rM78HKUJTr75uUXhFA@mail.gmail.com","threadId":"31861","inReplyTo":"CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com","subject":"Re: [msysGit] Re: Git for Windows and line endings","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2012-10-19T21:53:17Z","receivedAt":"2012-10-19T21:53:17Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Fri, Oct 19, 2012 at 10:39 AM, Chris B <chris.blaszczynski@gmail.com> wrote:\n[snip]\n> - Windows has been able to cope with UNIX line endings a long time; no\n> developer is using a default Notepad to open files with high\n> expectations. Any Windows development tool and editor worth anything\n> I've used is able to handle both just fine.\n\nThat's simply not a true, across the board statement.  I really wish\nit was, because I find the issue troublesome as well.  Unfortunately,\nthere are still plenty of applications that don't cope with mixed line\nendings very well.  We have a backend that targets several platforms,\nand the Windows toolchain is quite keen on having CRLF endings, but we\nlike LF under Linux, and others.\n\nI also wish that no developers were using Notepad either.  Any time\nI've run across it, I've tried to point folks at much more capable\nenvironments... but that only has moderate success.  Of course, it's\neven worse these days because Notepad puts a BOM at the front of the\nfile, making Git think it's a binary file.\n\nOne thing I do wish is that I didn't have to do the song and dance to\nconvert all the files when I set gitattributes:\n\n    $ echo \"* text=auto\" >>.gitattributes\n    $ rm .git/index     # Remove the index to force git to\n    $ git reset         # re-scan the working directory\n    $ git status        # Show files that will be normalized\n    $ git add -u\n    $ git add .gitattributes\n    $ git commit -m \"Introduce end-of-line normalization\"\n\nOne thing that I like about Subversion was that when you set\nsvn:eol-style, it took.\n\n-John\n"},{"id":"202512","messageId":"878vahee72.fsf@hariville.hurrynot.org","threadId":"31861","inReplyTo":"CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com","subject":"Re: [msysGit] Re: Git for Windows and line endings","fromName":"Raja R Harinath","fromEmail":"harinath@hurrynot.org","sentAt":"2012-11-04T12:37:53Z","receivedAt":"2012-11-04T12:37:53Z","isPatch":false,"sender":{"key":"harinath@hurrynot.org","avatar":"https://avatars.githubusercontent.com/u/4610?v=4"},"body":"Hi,\n\nChris B <chris.blaszczynski@gmail.com> writes:\n[snip]\n> - Windows has been able to cope with UNIX line endings a long time; no\n> developer is using a default Notepad to open files with high\n> expectations. Any Windows development tool and editor worth anything\n> I've used is able to handle both just fine.\n> - VIM also handles Windows line endings just fine as well. I just\n> tested it on a Linux machine. Maybe old version? (pure VI is not even\n> on this machine but hard to press these days it can't handle it.)\n> - The files in .git folder are in UNIX format anyway, so why are those\n> not also included in line ending changes? Isn't is because there is a\n> Windows app (msysgit) running on Windows that expects the UNIX line\n> ending? So in the same manor, someone might have a Windows system\n> using some Cygwin components perhaps, or a Windows C program possibly\n> poorly written or just old, that demand some text files to be left\n> alone in the format we saved it.\n\nThere are several subtleties in LF handling with mixed systems.  Here's\nmy write-up in:\n\n  https://github.com/mono/mono/blob/master/.gitattributes\n\nfor an example set of trade-offs.  Quoting in full since it's fairly short.\n\n- Hari\n\n# CRLF Handling\n# -------------\n#\n# The ideal situation would be to do no EOL normalization.  Each file\n# would have a default EOL, and tools on Windows and Linux would handle\n# both EOL formats.\n#\n# We're not in the ideal world.  A popular editor on Windows (possibly\n# Visual Studio) silently introduces EOL corruption -- it displays an\n# LF-file normally, but any newly added lines have CRLF.  On Linux,\n# Emacs and versions of VI handle LF-files and CRLF-files properly.\n# However, emacs doesn't like files with both LF and CRLF EOLs.  Editing\n# the file without additional action will increase the EOL corruption\n# in the file.\n#\n# Another vector for mixed EOLs is scripts.  We mostly don't have scripts\n# that add new lines -- so we rarely see this.  However, one major event\n# in the tree was the addition of copyright headers using a script.  That\n# script introduced EOL corruption.\n#\n# Any automated EOL normalization of files already in the repository will\n# cause difficulties in traversing histories, assigning blame, etc.  So, we\n# don't want to change what's in the repository significantly, even if it\n# causes trouble.\n#\n# What we do now:\n#\n# a) we ensure that there's no further corruption of LF-files.  So, we use\n#    git's 'crlf' attribute on those files to ensure that things are fine\n#    when we work on Windows.  We could use 'crlf=input', but it doesn't buy\n#    us much -- we might as well be working with consistent EOLs for files in\n#    working directories as well as in the repository\n#\n# b) if the file already of CRLFs, we don't do any normalization.  We use '-crlf'\n#    so that git doesn't do any EOL-conversion of the file.  As I said, this\n#    is mostly harmless on Linux.  We can't mark these files as 'crlf' or use\n#    the new (git 1.7.2) 'eol=crlf' attribute, since it changes the contents\n#    _inside_ the repository [1], and hence makes history traversal annoying.\n#    So, we live with occasional EOL corruption.\n#\n# c) We can handle mixed-EOL files on a case-by-case basis, converting them to\n#    LF- or CRLF-files based on which causes fewer lines to change\n#\n# d) We try to ensure no further headaches, by declaring EOL normalization on\n#    code files, and Unix-flavoured files, like shell-scripts, makefiles, etc.\n#\n# [1] GIT use LFs as the normalized internal representation.\n"}]}