{"thread":{"id":"11505","subject":"CRLF problems with Git on Win32","startedAt":"2008-01-07T09:16:50Z","lastAt":"2008-01-14T09:41:40Z","messageCount":113,"participants":["Peter Karlsson","Steffen Prohaska","Junio C Hamano","Jeff King","Peter Klavins","Robin Rosenberg","Johannes Schindelin","Linus Torvalds","Thomas Neumann","Gregory Jefferis","Marius Storm-Olsen","Gonzalo Garramuño","Peter Harris","Remi Vanicat","Kelvie Wong","J. Bruce Fields","Dmitry Potapov","Sean","Abdelrazak Younes","Jan Hudec","Rogan Dawes","Sam Ravnborg","Christer Weinigel","David Kågedal","Miles Bader"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64634","messageId":"Pine.LNX.4.64.0801071010340.1864@ds9.cixit.se","threadId":"11505","inReplyTo":null,"subject":"CRLF problems with Git on Win32","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2008-01-07T09:16:50Z","receivedAt":"2008-01-07T09:16:50Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\nWhen I clone git://git.debian.org/git/turqstat/turqstat.git using the\nmsys-Windows version of git (1.5.4-rc2), some but not all the files get\nautoconverted to CRLF. Is it possible to set properties for the files\nthat are text, to make sure they are converted properly?\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"64636","messageId":"5C0F88FD-AB2F-4BAD-ADEC-75428F14260F@zib.de","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801071010340.1864@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-07T09:57:52Z","receivedAt":"2008-01-07T09:57:52Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 7, 2008, at 10:16 AM, Peter Karlsson wrote:\n\n> When I clone git://git.debian.org/git/turqstat/turqstat.git using the\n> msys-Windows version of git (1.5.4-rc2), some but not all the files \n> get\n> autoconverted to CRLF. Is it possible to set properties for the files\n> that are text, to make sure they are converted properly?\n\nPer default, CRLF conversion is disabled in msysgit. Git should\nnot convert a single file. Does it really convert some?\n\nYou can verify that CRLF conversion is off by running\n\n git config core.autocrlf\n\nwhich should just print an empty line.\n\nYou can enable automatic conversion for all text files by running\n\n git config core.autocrlf true\n\n(this can be set on a per-repository basis or you can set a\n default for your account if you pass the '--global' option.)\n\nA difficulty you'll run into is that you need to set\n\"core.autocrlf true\" before you checkout. But because git clone\nfuses git init, git fetch, and git checkout into a single\noperation, you can't use it as is if you like to enable CRLF\non a per-repository basis (it works if you set a global default).\n\nYou can either use\n\n git clone -n URL # -n tells clone to stop before checkout\n cd turqstat\n git config core.autocrlf true\n git checkout -b master origin/master\n\nor you can manually do what clone would do for you, i.e.\n\n mkdir turqstat\n cd turqstat\n git init\n git config core.autocrlf true\n git remote add origin git://git.debian.org/git/turqstat/ \nturqstat.git\n git fetch origin\n git checkout -b master origin/master\n\n(this is what I typically do).\n\nBTW, I think that git clone should be improved to avoid the\nworkaround described above. Maybe it could ask the user if it\nshould set up a specific line ending conversion before checkout.\nUnfortunately, I had no time to write a patch, yet.\n\n\tSteffen\n"},{"id":"64637","messageId":"7vzlviymxw.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"5C0F88FD-AB2F-4BAD-ADEC-75428F14260F@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-07T10:00:59Z","receivedAt":"2008-01-07T10:00:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> Per default, CRLF conversion is disabled in msysgit.\n\nThat's interesting, as core.autocrlf was invented _specifically_\nfor use on Windows.\n"},{"id":"64638","messageId":"20080107101256.GA25047@coredump.intra.peff.net","threadId":"11505","inReplyTo":"5C0F88FD-AB2F-4BAD-ADEC-75428F14260F@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-07T10:12:56Z","receivedAt":"2008-01-07T10:12:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 07, 2008 at 10:57:52AM +0100, Steffen Prohaska wrote:\n\n> or you can manually do what clone would do for you, i.e.\n>\n> mkdir turqstat\n> cd turqstat\n> git init\n> git config core.autocrlf true\n> git remote add origin git://git.debian.org/git/turqstat/turqstat.git\n> git fetch origin\n> git checkout -b master origin/master\n>\n> (this is what I typically do).\n>\n> BTW, I think that git clone should be improved to avoid the\n> workaround described above. Maybe it could ask the user if it\n> should set up a specific line ending conversion before checkout.\n> Unfortunately, I had no time to write a patch, yet.\n\nI don't know if there are other options that might impact how clone\nworks, but something like the patch below might make sense. It would\nallow:\n\n git clone -c core.autocrlf=true ...\n\nNote that the patch should not be applied; it doesn't handle values with\nwhitespace (and hopefully builtin clone will come soon after v1.5.4,\nwhich would make doing it right much simpler).\n\n---\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex b4e858c..a002550 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -23,6 +23,7 @@ reference= reference repository\n o,origin= use instead of 'origin' to track upstream\n u,upload-pack= path to git-upload-pack on the remote\n depth= create a shallow clone of that depth\n+c,config= set a config option of the form key=value\n \n use-separate-remote compatibility, do not use\n no-separate-remote compatibility, do not use\"\n@@ -127,6 +128,7 @@ use_separate_remote=t\n depth=\n no_progress=\n local_explicitly_asked_for=\n+config=\n test -t 1 || no_progress=--no-progress\n \n while test $# != 0\n@@ -173,6 +175,9 @@ do\n \t--depth)\n \t\tshift\n \t\tdepth=\"--depth=$1\" ;;\n+\t-c|--config)\n+\t\tshift\n+\t\tconfig=\"$config $1\" ;;\n \t--)\n \t\tshift\n \t\tbreak ;;\n@@ -242,6 +247,12 @@ fi &&\n export GIT_DIR &&\n GIT_CONFIG=\"$GIT_DIR/config\" git-init $quiet ${template+\"$template\"} || usage\n \n+for i in $config; do\n+\tkey=`echo $i | cut -d= -f1`\n+\tvalue=`echo $i | cut -d= -f2-`\n+\tgit config $key $value\n+done\n+\n if test -n \"$bare\"\n then\n \tGIT_CONFIG=\"$GIT_DIR/config\" git config core.bare true\n"},{"id":"64639","messageId":"flsu0r$m9p$1@ger.gmane.org","threadId":"11505","inReplyTo":"5C0F88FD-AB2F-4BAD-ADEC-75428F14260F@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Klavins","fromEmail":"klavins@netspace.net.au","sentAt":"2008-01-07T10:13:31Z","receivedAt":"2008-01-07T10:13:31Z","isPatch":false,"sender":{"key":"klavins@netspace.net.au","avatar":"https://gravatar.com/avatar/7bb2403e1c2330c5c199171858cb3b7c1e9780f0cf0dbf44f2468fe4a6a8b079?d=mp&s=160"},"body":"I use an alternate workaround that clones the repository, removes the \nchecked out files, sets autocrlf, then checks out the files again:\n\n$ git clone git://git.debian.org/git/turqstat/turqstat.git\n$ cd turqstat\n$ git config --add core.autocrlf true\n$ rm -rf * .gitignore\n$ git reset --hard\n\nThe result should now be the same as using Steffen's system.\n\nHowever, there is still an unresolved problem with git's way of treating \ncr/lf as an attribute only of the checkout and not the repository itself:\n\n$ git status\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: visualc/.gitignore\n# modified: visualc/turqstat.sln\n# modified: visualc/turqstat.vcproj\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nSo, checking out the repository with cr/lf true has now caused misalignment \nof files that were originally checked in with existing cr/lf's in place. \nVisual Studio in fact happily works with files that only have lf endings, \n_except_ *.sln and *.vcproj files, which it much prefers to have with cr/lf \nendings.\n\nThe _real_ solution to this problem for the moment is _not_ to mix files \nwith both lf and cr/lf endings in the repository.\n\nSo, the original author of the repository should _also_ have used \ncore.autocrlf true, thus causing the *sln and *vcproj to have their cr's \nstripped on checkin, but replaced on checkout when checking out with \nautocrlf true.\n\n------------------------------------------------------------------------\n Peter Klavins \n"},{"id":"64647","messageId":"2F7A8304-A34E-4870-A877-EEBAC9D74EF9@zib.de","threadId":"11505","inReplyTo":"7vzlviymxw.fsf@gitster.siamese.dyndns.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-07T12:15:17Z","receivedAt":"2008-01-07T12:15:17Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 7, 2008, at 11:00 AM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>> Per default, CRLF conversion is disabled in msysgit.\n>\n> That's interesting, as core.autocrlf was invented _specifically_\n> for use on Windows.\n\nMy take on this is that is was invented for cross-platform projects.\n\nBut if you have a Windows-only project it does not make sense to\nconvert line endings. Only if you plan to work on multiple\nplatforms, line ending conversion makes sense. The most\nconservative choice is to leave content unmodified. This is true\nfor Windows, as it is for Unix. Therefore, msysgit does not\nmodify your content unless requested otherwise.\n\n\tSteffen\n"},{"id":"64649","messageId":"4228FF68-2C9A-49A4-B9E5-406D2FB09EB9@zib.de","threadId":"11505","inReplyTo":"flsu0r$m9p$1@ger.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-07T12:58:21Z","receivedAt":"2008-01-07T12:58:21Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 7, 2008, at 11:13 AM, Peter Klavins wrote:\n\n> I use an alternate workaround that clones the repository, removes \n> the checked out files, sets autocrlf, then checks out the files again:\n>\n> $ git clone git://git.debian.org/git/turqstat/turqstat.git\n> $ cd turqstat\n> $ git config --add core.autocrlf true\n> $ rm -rf * .gitignore\n> $ git reset --hard\n>\n> The result should now be the same as using Steffen's system.\n\nYes, this should yield the same.\n\n\n> However, there is still an unresolved problem with git's way of \n> treating cr/lf as an attribute only of the checkout and not the \n> repository itself:\n>\n> $ git status\n> # On branch master\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> #\n> # modified: visualc/.gitignore\n> # modified: visualc/turqstat.sln\n> # modified: visualc/turqstat.vcproj\n> #\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>\n> So, checking out the repository with cr/lf true has now caused \n> misalignment of files that were originally checked in with existing \n> cr/lf's in place. Visual Studio in fact happily works with files \n> that only have lf endings, _except_ *.sln and *.vcproj files, which \n> it much prefers to have with cr/lf endings.\n\nYou could try .gitattributes to exclude files from crlf\nconversion. But I'd not recommend this, because the mechanism\nhas some deficiencies, as discussed in\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/61888\n\n\n> The _real_ solution to this problem for the moment is _not_ to mix \n> files with both lf and cr/lf endings in the repository.\n\nThis is the way to go.\n\n\n> So, the original author of the repository should _also_ have used \n> core.autocrlf true, thus causing the *sln and *vcproj to have their \n> cr's stripped on checkin, but replaced on checkout when checking \n> out with autocrlf true.\n\nFor cross-platform projects, I recommend to explicitly configure\nautocrlf on Windows and Unix. On Windows set\n\n git config core.autocrlf true # on Windows\n\nand on Unix set\n\n git config core.autocrlf input # on Unix\n\nThis ensures that the repository only contains LF. Even if someone\nemails source code from Windows to Unix and commits it there.\n\n\tSteffen\n"},{"id":"64651","messageId":"Pine.LNX.4.64.0801071447320.1864@ds9.cixit.se","threadId":"11505","inReplyTo":"flsu0r$m9p$1@ger.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2008-01-07T13:50:08Z","receivedAt":"2008-01-07T13:50:08Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Steffen Prohaska:\n\n> Per default, CRLF conversion is disabled in msysgit. Git should\n> not convert a single file. Does it really convert some?\n\nI didn't verify, but it was only some files that had LFs, perhaps the\nfiles that I added while on the Windows machine had CRLFs. That's bad.\n\n\nPeter Klavins:\n\n> Visual Studio in fact happily works with files that only have lf\n> endings, _except_ *.sln and *.vcproj files, which it much prefers to\n> have with cr/lf endings.\n\nThe project files were added to the repository on the Windows box\n(obviously), so those are correct.\n\n\nSo apparently my repository is a bit broken at the moment with LF on\nsome files and CRLF on some. That's bad. I just assumed everything\nworked, it used to \"just work\" for CVS (except for when you actually\ntried to add binary files, of course).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"64652","messageId":"fltc4g$6m8$1@ger.gmane.org","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801071447320.1864@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Klavins","fromEmail":"klavins@netspace.net.au","sentAt":"2008-01-07T14:14:21Z","receivedAt":"2008-01-07T14:14:21Z","isPatch":false,"sender":{"key":"klavins@netspace.net.au","avatar":"https://gravatar.com/avatar/7bb2403e1c2330c5c199171858cb3b7c1e9780f0cf0dbf44f2468fe4a6a8b079?d=mp&s=160"},"body":"> So apparently my repository is a bit broken at the moment with LF on\n> some files and CRLF on some. That's bad. I just assumed everything\n> worked, it used to \"just work\" for CVS (except for when you actually\n> tried to add binary files, of course).\n\nLOL. Exactly. That's my only gripe with git, there's still some way to go \nbefore it's as usable as CVS in this regard, but of course in every other \nfeature it's way superior.\n\nIf you follow the steps I listed, you will have new .sln and .vcproj files \nthat you can commit over the top of the ones already there, and everything \nwill be fixed! I checked out your project and it built fine.\n\n------------------------------------------------------------------------\n Peter Klavins \n"},{"id":"64653","messageId":"9D6F756F-2709-4F8E-8DBB-298DD4B49C66@zib.de","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801071447320.1864@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-07T16:05:26Z","receivedAt":"2008-01-07T16:05:26Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 7, 2008, at 2:50 PM, Peter Karlsson wrote:\n\n> Steffen Prohaska:\n>\n>> Per default, CRLF conversion is disabled in msysgit. Git should\n>> not convert a single file. Does it really convert some?\n>\n> I didn't verify, but it was only some files that had LFs, perhaps the\n> files that I added while on the Windows machine had CRLFs. That's bad.\n\nThis is a typical problem. Once CRLFs are in your repository\nautocrlf can't \"just work\" anymore. You need to commit a fixed\nversion of the files.\n\n\n> Peter Klavins:\n>\n>> Visual Studio in fact happily works with files that only have lf\n>> endings, _except_ *.sln and *.vcproj files, which it much prefers to\n>> have with cr/lf endings.\n>\n> The project files were added to the repository on the Windows box\n> (obviously), so those are correct.\n>\n>\n> So apparently my repository is a bit broken at the moment with LF on\n> some files and CRLF on some. That's bad. I just assumed everything\n> worked, it used to \"just work\" for CVS (except for when you actually\n> tried to add binary files, of course).\n\n\"Just works\" has a different meaning for git than it has for CVS.\nFor git, it means that once you _told_ git how to convert line\nendings (that is you have correctly configured autocrlf), git\nwill automatically detect text files and convert them, but leave\nbinary files untouched. It \"just works\" in the sense that you do\nnot need to explicitly tell git about every single binary files\n(no cvs -kb needed). Git will auto-detect the file type.\n\nBut if you does tell git to convert line endings it \"just works\"\nas if every file was binary. Per default, git does not modify\nyour content. And for some people, \"just works\" means exactly\nthis: leave my content as is.\n\nSo it really depends on the context and therefore some\nconfiguration is inevitable. git requires you to configure\nautocrlf. cvs requires you to set -kb.\n\nYou may, though, set \"core.autocrlf true\" globally for your\naccount. After you did this, git should \"just work\" for you; if\n\"just works\" means convert CRLF in _all_ text files in _every_\nrepository.\n\n\tSteffen\n"},{"id":"64659","messageId":"200801071947.28586.robin.rosenberg.lists@dewire.com","threadId":"11505","inReplyTo":"20080107101256.GA25047@coredump.intra.peff.net","subject":"Re: CRLF problems with Git on Win32","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-01-07T18:47:28Z","receivedAt":"2008-01-07T18:47:28Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndagen den 7 januari 2008 skrev Jeff King:\n> On Mon, Jan 07, 2008 at 10:57:52AM +0100, Steffen Prohaska wrote:\n> \n> I don't know if there are other options that might impact how clone\n> works, but something like the patch below might make sense. It would\n> allow:\n> \n> git clone -c core.autocrlf=true ...\n\nYou can also set the option globally. Maybe something for the installer or a first time wizard.\nBut I do think git should have this option set right from the beginning. It could print out somethig\nto notify the user that (and which) some options are not set the same as on unix.\n\n-- robin\n"},{"id":"64660","messageId":"alpine.LSU.1.00.0801071915470.10101@racer.site","threadId":"11505","inReplyTo":"200801071947.28586.robin.rosenberg.lists@dewire.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-07T19:16:32Z","receivedAt":"2008-01-07T19:16:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 7 Jan 2008, Robin Rosenberg wrote:\n\n> måndagen den 7 januari 2008 skrev Jeff King:\n> > On Mon, Jan 07, 2008 at 10:57:52AM +0100, Steffen Prohaska wrote:\n> > \n> > I don't know if there are other options that might impact how clone \n> > works, but something like the patch below might make sense. It would \n> > allow:\n> > \n> > git clone -c core.autocrlf=true ...\n> \n> You can also set the option globally. Maybe something for the installer \n> or a first time wizard.\n\nWe thought about that, too.\n\n> But I do think git should have this option set right from the beginning.\n\nProblem. There is not a single \"right\". It really depends on the \nproject.\n\nCiao,\nDscho\n"},{"id":"64666","messageId":"200801072203.23938.robin.rosenberg.lists@dewire.com","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801071915470.10101@racer.site","subject":"Re: CRLF problems with Git on Win32","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-01-07T21:03:23Z","receivedAt":"2008-01-07T21:03:23Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndagen den 7 januari 2008 skrev du:\n> Problem. There is not a single \"right\". It really depends on the \n> project.\n\nIndeed, but the most common SCM's detect binary files automatically, \neither by suffix or content analysis, so I think that is what user's expect.\nIt will be right for more projects that the current behaviour.\n\n-- robin\n"},{"id":"64671","messageId":"alpine.LSU.1.00.0801072115120.10101@racer.site","threadId":"11505","inReplyTo":"200801072203.23938.robin.rosenberg.lists@dewire.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-07T21:18:00Z","receivedAt":"2008-01-07T21:18:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[msysGit Cc'ed, since it is massively concerned by this thread]\n\nOn Mon, 7 Jan 2008, Robin Rosenberg wrote:\n\n> måndagen den 7 januari 2008 skrev du:\n> > Problem. There is not a single \"right\". It really depends on the \n> > project.\n> \n> Indeed, but the most common SCM's detect binary files automatically, \n> either by suffix or content analysis, so I think that is what user's \n> expect. It will be right for more projects that the current behaviour.\n\nSteffen also fought for turning this on by default, but so far I resisted. \nFor a good reason: the primary user of msysGit for the moment is... \nmsysGit. And this project does not need CR for obvious reasons.\n\nBut I imagine that it makes sense for the Git installers. Colour me \nno-longer-resisting.\n\nCiao,\nDscho\n"},{"id":"64673","messageId":"alpine.LFD.1.00.0801071332530.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"200801072203.23938.robin.rosenberg.lists@dewire.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-07T21:36:45Z","receivedAt":"2008-01-07T21:36:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 7 Jan 2008, Robin Rosenberg wrote:\n> \n> Indeed, but the most common SCM's detect binary files automatically, \n> either by suffix or content analysis, so I think that is what user's expect.\n> It will be right for more projects that the current behaviour.\n\nYeah, I suspect it's not only the \"expected\" behavior, but people have had \nyears of getting used to the whole binary issue, and are much more likely \nto expect binary corruption than to expect to have to worry about CRLF.\n\nAnd while it's true that it probably doesn't matter at all as long as you \nstay windows-only (and everything is CRLF), it's also true that (a) maybe \nyou don't necessarily even know that some day you might want to cast off \nthe shackles of MS and (b) even under Windows you do end up having some \nstrange tools end up using LF (ie you may be using some tools that were \njust straight ports from Unix, and that write just LF).\n\nSo defaulting to (or asking) \"autocrlf\" at install time is probably the \nsafest thing, and then people can edit their global .gitconfig to turn it \noff.\n\n\t\t\tLinus\n"},{"id":"64674","messageId":"3B08AC4C-A807-4155-8AD7-DC6A6D0FE134@zib.de","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801072115120.10101@racer.site","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-07T21:40:56Z","receivedAt":"2008-01-07T21:40:56Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 7, 2008, at 10:18 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> [msysGit Cc'ed, since it is massively concerned by this thread]\n>\n> On Mon, 7 Jan 2008, Robin Rosenberg wrote:\n>\n>> måndagen den 7 januari 2008 skrev du:\n>>> Problem. There is not a single \"right\". It really depends on the\n>>> project.\n>>\n>> Indeed, but the most common SCM's detect binary files automatically,\n>> either by suffix or content analysis, so I think that is what user's\n>> expect. It will be right for more projects than the current \n>> behaviour.\n>\n> Steffen also fought for turning this on by default, but so far I \n> resisted.\n> For a good reason: the primary user of msysGit for the moment is...\n> msysGit. And this project does not need CR for obvious reasons.\n>\n> But I imagine that it makes sense for the Git installers. Colour me\n> no-longer-resisting.\n\nEventually I gave in and even voted for \"Git does not modify\ncontent unless explicitly requested otherwise\".\n\nHere's the full discussion:\n\nhttp://code.google.com/p/msysgit/issues/detail?id=21\n\nI believe the main question is which type of projects we would like\nto support by our default. For real cross-platform projects that will\nbe checked out on Windows and Unix we should choose\n\"core.autocrlf true\" as our default. But if our default are native\nWindows projects that will never be checked out on Unix, then we\nshould not set core.autocrlf by default.\n\nI once fought for \"real cross-platform\", because this is what I need\nin my daily work. Note, however, that this setting bears the slight\nchance of git failing to correctly detect a binary file. In this case\ngit would corrupt the file. So there is a tiny chance of data loss\nwith \"core.autocrlf true\". The safest choice is to leave core.autocrlf\nunset.\n\n\tSteffen\n"},{"id":"64675","messageId":"20080107224204.55539c31@jaiman","threadId":"11505","inReplyTo":"200801072203.23938.robin.rosenberg.lists@dewire.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Thomas Neumann","fromEmail":"tneumann@users.sourceforge.net","sentAt":"2008-01-07T21:42:04Z","receivedAt":"2008-01-07T21:42:04Z","isPatch":false,"sender":{"key":"tneumann@users.sourceforge.net","avatar":null},"body":"> Indeed, but the most common SCM's detect binary files automatically, \n> either by suffix or content analysis, so I think that is what user's\n> expect. It will be right for more projects that the current behaviour.\nas a user, I expect a SCM to only modify a file when I have explicitly\nasked it to do so. Automatically conversion by guessing file types are\nevil, as they _will_ go wrong, and then mess some files.\nThis \"intelligent\" file handling is a pain to use. You end up in\nsituations were builds work on some platforms but not on others, which\ngets even more confusion with NFS home directories.\n\nSo, please do not enable core.autocrlf by default on Windows. It might\nbe reasonable for some projects, but not for all of them, and it will\nbreak some projects. Perhaps a project should be able to enable (or\n\"suggest\" it) in a repo-wide setting somehow, which would avoid the git\nclone problem.\n\nThomas\n"},{"id":"64679","messageId":"7vzlvhxpda.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"3B08AC4C-A807-4155-8AD7-DC6A6D0FE134-wjoc1KHpMeg@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster-e+axbwqsrlaavxtiumwx3w@public.gmane.org","sentAt":"2008-01-07T22:06:09Z","receivedAt":"2008-01-07T22:06:09Z","isPatch":false,"sender":{"key":"gitster-e+axbwqsrlaavxtiumwx3w@public.gmane.org","avatar":null},"body":"\nSteffen Prohaska writes:\n\n> I believe the main question is which type of projects we would like\n> to support by our default. For real cross-platform projects that will\n> be checked out on Windows and Unix we should choose\n> \"core.autocrlf true\" as our default. But if our default are native\n> Windows projects that will never be checked out on Unix, then we\n> should not set core.autocrlf by default.\n\nIf the primary target is native Windows projects that wants CRLF\nin the work tree, you could still set core.autocrlf. Your\ncheckouts will be with CRLF. And someday perhaps somebody may\noffer porting that to UNIX and his checkout will be without CR.\n\nSo wouldn't the categorization be more like this?\n\n - \"real cross-platform\" would want core.autocrlf = true;\n\n - \"native Windows\" can work either way;\n\n - \"originated from UNIX\" would be helped with core.autocrlf = true;\n"},{"id":"64683","messageId":"alpine.LFD.1.00.0801071457040.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"7vzlvhxpda.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org","sentAt":"2008-01-07T22:58:46Z","receivedAt":"2008-01-07T22:58:46Z","isPatch":false,"sender":{"key":"torvalds-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org","avatar":null},"body":"\n\n\nOn Mon, 7 Jan 2008, Junio C Hamano wrote:\n> \n> So wouldn't the categorization be more like this?\n\nWell, one thng we could do is to add a new concept, namely\n\n\tcore.autocrlf = warn\n\nand make *that* the default.\n\nIt would do the check, but not actually convert anything, just warn about \nit.\n\nThen, it's up to the user to set it explicitly to \"true\" or \"false\", \nunless they just like seeing that warning a million times ;)\n\nThat might be acceptable to most people.\n\n\t\tLinus\n"},{"id":"64688","messageId":"C3A86A49.10AEF%jefferis@gmail.com","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801071457040.3148-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Gregory Jefferis","fromEmail":"jefferis-re5jqeeqqe8avxtiumwx3w@public.gmane.org","sentAt":"2008-01-07T23:46:17Z","receivedAt":"2008-01-07T23:46:17Z","isPatch":false,"sender":{"key":"jefferis-re5jqeeqqe8avxtiumwx3w@public.gmane.org","avatar":null},"body":"\nOn 7/1/08 22:58, \"Linus Torvalds\" wrote:\n\n> Well, one thng we could do is to add a new concept, namely\n> \n> core.autocrlf = warn\n> \n> and make *that* the default.\n> \n> It would do the check, but not actually convert anything, just warn about\n> it.\n> \n\nI think this is the best option so far. Since this doesn't exist I was just\nwriting a hook for myself which fails rather than warns when CRLFs are\ndetected. Not modifying content by default is a good mantra. But getting a\ncouple of CRLF files into the repository and then noticing n commits down\nthe line and having to run a filter-branch session is a pain. So +1 for the\ndefault being a warning (that includes appropriate instructions) when\ncommitting a file that looks like text but has CRLF. And having a \"fail\"\noption might be nice while you(?)'re at it:\n\ncore.autocrlf = fail # refuse to commit text files containing CRLF\n\nGreg. \n\nPS Of course none of this would have helped me with those old mac CR files\nthat got into another repository ...\n"},{"id":"64705","messageId":"5310CD2F-C3B4-404A-9C2E-1D3084B5CC96@zib.de","threadId":"11505","inReplyTo":"7vzlvhxpda.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska-wjoc1khpmeg@public.gmane.org","sentAt":"2008-01-08T07:02:47Z","receivedAt":"2008-01-08T07:02:47Z","isPatch":false,"sender":{"key":"prohaska-wjoc1khpmeg@public.gmane.org","avatar":null},"body":"\n\nOn Jan 7, 2008, at 11:06 PM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>> I believe the main question is which type of projects we would like\n>> to support by our default. For real cross-platform projects that \n>> will\n>> be checked out on Windows and Unix we should choose\n>> \"core.autocrlf true\" as our default. But if our default are native\n>> Windows projects that will never be checked out on Unix, then we\n>> should not set core.autocrlf by default.\n>\n> If the primary target is native Windows projects that wants CRLF\n> in the work tree, you could still set core.autocrlf. Your\n> checkouts will be with CRLF. And someday perhaps somebody may\n> offer porting that to UNIX and his checkout will be without CR.\n>\n> So wouldn't the categorization be more like this?\n>\n> - \"real cross-platform\" would want core.autocrlf = true;\n>\n> - \"native Windows\" can work either way;\n\nBut core.autocrlf = true has a slight danger of data corruption.\nAFAIK, git's binary detection checks the first \"few\" bytes (with\nfew = 8000). This may be sufficient in most case, but I already\nmet a file that was wrongly classified. (A File format that\nstarts with a large ASCII header and has chunks of binary data\nattached later.)\n\n\n> - \"originated from UNIX\" would be helped with core.autocrlf = true;\n\nI'd say \"could be helped\". For the msysgit development, for\nexample, we do _not_ want to have core.autocrlf = true but\nprefer to preserve the Unix line ending even when working on\nWindows. We have only few Windows-specific files that are\ncommitted with CRLF. We _know_ the problem and we explicitly\nhandle it.\n\n\nI believe, best would be if a line ending policy could be\nconfigured for a project. Then, the decision could be made once\nfor the project and should be enforced on all clones. But\ncurrently git has no concept for this.\n\nA sound policy for \"real cross-platform\" is that CRLF must never\nenter the repository unless git detects a file as binary, or a\nfile is explicitly listed in .gitattributes. It doesn't really\nmatter if Windows users check out files with CRLF or LF. It only\nmatters that they'll never commit a file with CRLF. Note, the\nsame is true for Unix users. People could send code by email or\ncopy source files from Windows to Unix machines. Then, CRLF\nwould enter the repo on Unix. So the least that should be set\nfor this type of projects on any OS is core.autocrlf = input.\nOn Windows, core.autocrlf = true is probably more natural.\n\nI like Linus' idea of \"warn\" or Gregory's \"fail\".\n\nWould \"warn/fail\" be the default on Unix, too? Then Unix users\nwould also be forced to make an explicit choice. Maybe some day\nthey want to check out their project on Windows and they should\nbe prepared now. For typical files, the warning (or error) would\nnever trigger. But maybe one day they copy a file from a Windows\nmachine and forget to run dos2unix. In this case, git would warn\nthem unless they set \"core.autocrlf = false\".\n\nI'm asking the last question because every Unix developer should\nthink about the option, too. Neither Unix or Windows are causing\nthe problem alone. It's the combination in a cross-platform\nproject. Git could ensure that any repository is in principal\nprepared for cross-platform, unless explicitly told not to do so.\n\nSo, would you, as Linux developers, like to have (or accept)\n\"warn/fail\" as your default?\n\nThis would make things easy for the msysgit project: No Windows\nspecific configuration; just official git.\n\n\tSteffen\n"},{"id":"64713","messageId":"7vejcswzad.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"5310CD2F-C3B4-404A-9C2E-1D3084B5CC96@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-08T07:29:30Z","receivedAt":"2008-01-08T07:29:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\n\n\nSteffen Prohaska writes:\n\n> But core.autocrlf = true has a slight danger of data corruption.\n> AFAIK, git's binary detection checks the first \"few\" bytes (with\n> few = 8000). This may be sufficient in most case, but I already\n> met a file that was wrongly classified. (A File format that\n> starts with a large ASCII header and has chunks of binary data\n> attached later.)\n\nI presume that's where .gitattributes kicks in.\n\n> I like Linus' idea of \"warn\" or Gregory's \"fail\".\n\nYeah, that feels like a sensible thing to do.\n\n> I'm asking the last question because every Unix developer should\n> think about the option, too. Neither Unix or Windows are causing\n> the problem alone.\n\nThat's the logical conclusion.\n\nIf you are introducing crlf = warn, that means you are declaring\nthat CRLF should be treated as a disease, and that should apply\neverywhere, not just on Windows (which some people may consider\na disease itself, but that is a separate topic).\n"},{"id":"64710","messageId":"47833A66.9080007@gmail.com","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801071457040.3148-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Marius Storm-Olsen","fromEmail":"mstormo-re5jqeeqqe8avxtiumwx3w@public.gmane.org","sentAt":"2008-01-08T08:55:02Z","receivedAt":"2008-01-08T08:55:02Z","isPatch":false,"sender":{"key":"mstormo-re5jqeeqqe8avxtiumwx3w@public.gmane.org","avatar":null},"body":"\nLinus Torvalds said the following on 07.01.2008 23:58:\n> \n> \n> On Mon, 7 Jan 2008, Junio C Hamano wrote:\n>> So wouldn't the categorization be more like this?\n> \n> Well, one thng we could do is to add a new concept, namely\n> \n> \tcore.autocrlf = warn\n> \n> and make *that* the default.\n> \n> It would do the check, but not actually convert anything, just warn about \n> it.\n> \n> Then, it's up to the user to set it explicitly to \"true\" or \"false\", \n> unless they just like seeing that warning a million times ;)\n> \n> That might be acceptable to most people.\n\nI actually would want the default to be\n core.autocrlf = windows\n\nMeaning, it would be true on Windows platforms, and warn on all \nothers. That way it would work as expected in 90% of the time, namely \nthat files are added to the repo with unix line endings. We could then \nadd the following warning when you try to add a CRLF file on \nnon-Windows platforms:\n\n * CRLF line endings detected for text files: , , \n Consider adding the following to a .gitattributes file to\n maintain the CRLF line endings on all platforms:\n = -crlf\n = -crlf\n = -crlf\n\nMaybe then can we lure non-Windows users to add these required \n.gitattributes files for files that need to be CRLF on all platforms; \ninstead of shoving the whole burden of maintaining a proper \ncross-platform repo onto the Windows users alone.\n\n/me braces for the \"it's your fault for working on Windows in the \nfirst place!\" flood ;-)\n\nOf course, setting the core.autocrlf = true|false should not show the \nwarning, for users who don't care about repo portability to Windows \nanyways.\n\n--\n.marius\n"},{"id":"64718","messageId":"20080108100818.GA17205@coredump.intra.peff.net","threadId":"11505","inReplyTo":"7vejcswzad.fsf@gitster.siamese.dyndns.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-08T10:08:18Z","receivedAt":"2008-01-08T10:08:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 07, 2008 at 11:29:30PM -0800, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n\nI'm not sure what's causing it, but all of the addresses in your message\n(including cc headers) got munged.\n\n> > I'm asking the last question because every Unix developer should\n> > think about the option, too. Neither Unix or Windows are causing\n> > the problem alone.\n> \n> That's the logical conclusion.\n> \n> If you are introducing crlf = warn, that means you are declaring\n> that CRLF should be treated as a disease, and that should apply\n> everywhere, not just on Windows (which some people may consider\n> a disease itself, but that is a separate topic).\n\nIt's unclear to me: is such a warning only supposed to happen when we\nsee CRLF _after_ we have determined that a file is not actually binary?\nOtherwise, it seems like we are punishing people on sane platforms who\nuse binary files (although even with that check, I am slightly\nuncomfortable given reports of incorrect guessing).\n\n-Peff\n"},{"id":"64720","messageId":"7v4pdovc4e.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"20080108100818.GA17205@coredump.intra.peff.net","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-08T10:35:13Z","receivedAt":"2008-01-08T10:35:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Jan 07, 2008 at 11:29:30PM -0800, Junio C Hamano wrote:\n>\n>> Steffen Prohaska writes:\n>\n> I'm not sure what's causing it, but all of the addresses in your message\n> (including cc headers) got munged.\n\nI think Steffen's original got munged (I just replied to it) by\ngmane's mail relaying interface.\n\n>> > I'm asking the last question because every Unix developer should\n>> > think about the option, too. Neither Unix or Windows are causing\n>> > the problem alone.\n>> \n>> That's the logical conclusion.\n>> \n>> If you are introducing crlf = warn, that means you are declaring\n>> that CRLF should be treated as a disease, and that should apply\n>> everywhere, not just on Windows (which some people may consider\n>> a disease itself, but that is a separate topic).\n>\n> It's unclear to me: is such a warning only supposed to happen when we\n> see CRLF _after_ we have determined that a file is not actually binary?\n\nOh, I agree. I thought that was what Steffen was proposing.\n"},{"id":"64721","messageId":"Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se","threadId":"11505","inReplyTo":"20080107224204.55539c31@jaiman","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2008-01-08T10:56:00Z","receivedAt":"2008-01-08T10:56:00Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Thomas Neumann:\n\n> as a user, I expect a SCM to only modify a file when I have\n> explicitly asked it to do so.\n\nAs a user, I exepect things to just work. With RCS/CVS/Subversion, it\ndoes, because it differentiates between text files (internally encoding\nNLs with \"LF\", but I couldn't care less what it uses there) and binary\nfiles (which it doesn't change). With git it currently doesn't since it\ntreats everything as binary files.\n\nYes, it's the whole text vs. binary file issue. We do live in a world\nwhere different systems store text differently. We have to deal with\nit. Preferrably, the computer should deal with it without me having to\ndo anything about it. After all, that's what computers are good at.\n\nIf I occasionally need to do a\n\n git add -kb binary.txt\n\nto flag a file explicitely, that's a small price to pay for everything\nelse to work out of the box.\n\n\nFWIW, I wouldn't care if git internally stored all texts as SCSU/BOCU\n(or UTF-32, for that matter, if Git's compression engine is better than\nSCSU or BOCU) using PARAGRAPH SEPARATOR to separate lines, just as\nlong as I could get back the text I checked in. Come to think about it,\nlocale autoconversion of text files would be a nice way to work between\nsystems that want different encodings, like how Windows prefers\nUTF-16LE, Mac OS X prefers UTF-8 and Linux systems prefers whatever I\nhave set my locale to (I still use iso-8859-1, so shoot me).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"64723","messageId":"20080108110757.GB18087@coredump.intra.peff.net","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-08T11:07:57Z","receivedAt":"2008-01-08T11:07:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 08, 2008 at 11:56:00AM +0100, Peter Karlsson wrote:\n\n> If I occasionally need to do a\n> \n> git add -kb binary.txt\n> \n> to flag a file explicitely, that's a small price to pay for everything\n> else to work out of the box.\n\nFor you, perhaps, since you apparently infrequently commit binary files\nand derive some benefit from CRLF conversion. But please bear in mind\nthat there are people on the other end of the spectrum who want the\nopposite (i.e., who could care less about CRLF, but _do_ have binary\nfiles).\n\n-Peff\n"},{"id":"64722","messageId":"47835A02.80404@advancedsl.com.ar","threadId":"11505","inReplyTo":"C3A86A49.10AEF%jefferis@gmail.com","subject":"git and unicode","fromName":"Gonzalo Garramuño","fromEmail":"ggarra@advancedsl.com.ar","sentAt":"2008-01-08T11:09:54Z","receivedAt":"2008-01-08T11:09:54Z","isPatch":false,"sender":{"key":"ggarra@advancedsl.com.ar","avatar":null},"body":"\nForking a little from the recent CR/LF thread, I was wondering how does \ngit deal with unicode files?\n\nMost scripting languages (ruby, python, etc) are now allowing their \nsource code to be written in unicode (UTF-8, usually). Will git \nincorrectly categorize those source files as \"binary\"?\n\n\n-- \nGonzalo Garramuño\nggarra@advancedsl.com.ar\n\nAMD4400 - ASUS48N-E\nGeForce7300GT\nXubuntu Gutsy\n"},{"id":"64727","messageId":"alpine.LSU.1.00.0801081151450.10101@racer.site","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-08T11:52:14Z","receivedAt":"2008-01-08T11:52:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 8 Jan 2008, Peter Karlsson wrote:\n\n> Thomas Neumann:\n> \n> > as a user, I expect a SCM to only modify a file when I have\n> > explicitly asked it to do so.\n> \n> As a user, I exepect things to just work. With RCS/CVS/Subversion, it \n> does, because it differentiates between text files (internally encoding \n> NLs with \"LF\", but I couldn't care less what it uses there) and binary \n> files (which it doesn't change). With git it currently doesn't since it \n> treats everything as binary files.\n\nHey, if Subversion does what you want, why not just use \nit?\n\nCiao,\nDscho\n"},{"id":"64728","messageId":"alpine.LSU.1.00.0801081152360.10101@racer.site","threadId":"11505","inReplyTo":"20080108110757.GB18087@coredump.intra.peff.net","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-08T11:54:49Z","receivedAt":"2008-01-08T11:54:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 8 Jan 2008, Jeff King wrote:\n\n> On Tue, Jan 08, 2008 at 11:56:00AM +0100, Peter Karlsson wrote:\n> \n> > If I occasionally need to do a\n> > \n> > git add -kb binary.txt\n> > \n> > to flag a file explicitely, that's a small price to pay for everything \n> > else to work out of the box.\n> \n> For you, perhaps, since you apparently infrequently commit binary files \n> and derive some benefit from CRLF conversion. But please bear in mind \n> that there are people on the other end of the spectrum who want the \n> opposite (i.e., who could care less about CRLF, but _do_ have binary \n> files).\n\nDo not forget the people who say that git is a content tracker (as opposed \nto a content munger). Git was really intended as a tracker of octet \nstrings which are organised in tree structures, and where you can have \nrevisions over those tree structures.\n\nThat is the beauty of git: it keeps simple things simple. Now, for some, \nthis is a curse ;-)\n\nCiao,\nDscho\n"},{"id":"64731","messageId":"C3A91B14.10B40%jefferis@gmail.com","threadId":"11505","inReplyTo":"20080108100818.GA17205@coredump.intra.peff.net","subject":"Re: CRLF problems with Git on Win32","fromName":"Gregory Jefferis","fromEmail":"jefferis@gmail.com","sentAt":"2008-01-08T12:20:36Z","receivedAt":"2008-01-08T12:20:36Z","isPatch":false,"sender":{"key":"jefferis@gmail.com","avatar":"https://gravatar.com/avatar/8528f4e227ebc88380c203c816e263246064e31f6180681dc2c6dabfaff24d6b?d=mp&s=160"},"body":"On 8/1/08 10:08, \"Jeff King\" wrote:\n\n>> If you are introducing crlf = warn, that means you are declaring\n>> that CRLF should be treated as a disease, and that should apply\n>> everywhere, not just on Windows (which some people may consider\n>> a disease itself, but that is a separate topic).\n> \n> It's unclear to me: is such a warning only supposed to happen when we\n> see CRLF _after_ we have determined that a file is not actually binary?\n> Otherwise, it seems like we are punishing people on sane platforms who\n> use binary files (although even with that check, I am slightly\n> uncomfortable given reports of incorrect guessing).\n\nIn the context of EOL style, a warning or error should only be given if we\nthink the file is text. Very occasionally we will be wrong about this, but\nif the default behaviour is warn then that will just be a minor annoyance.\nThis annoyance can be overcome for a file or file type (with attributes),\nper project or globally. If the default behaviour were munge (e.g.\nautocrlf=true) then we could very occasionally damage something, so I think\nwe can all agree that is a bad idea.\n\nGreg.\n"},{"id":"64734","messageId":"eaa105840801080507j1b748fy6fdff8b240cf8c33@mail.gmail.com","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Harris","fromEmail":"peter@peter.is-a-geek.org","sentAt":"2008-01-08T13:07:15Z","receivedAt":"2008-01-08T13:07:15Z","isPatch":false,"sender":{"key":"peter@peter.is-a-geek.org","avatar":null},"body":"On Jan 8, 2008 5:56 AM, Peter Karlsson wrote:\n> Thomas Neumann:\n>\n> > as a user, I expect a SCM to only modify a file when I have\n> > explicitly asked it to do so.\n>\n> As a user, I exepect things to just work. With RCS/CVS/Subversion, it\n> does, because it differentiates between text files (internally encoding\n> NLs with \"LF\", but I couldn't care less what it uses there) and binary\n> files (which it doesn't change). With git it currently doesn't since it\n> treats everything as binary files.\n\nActually, Subversion does the Right Thing, and treats everything as a\nbinary file until and unless you explicitly set the svn:eol-style\nproperty on each file that you want it to mangle.\n\nMaybe you set up Subversion auto-props and forgot about it? That would\nbe almost (but not really) like setting autocrlf=true in your global\ngit config.\n\nPeter Harris\n"},{"id":"64744","messageId":"87fxx8uzf4.dlv@vanicat.homelinux.org","threadId":"11505","inReplyTo":"47835A02.80404@advancedsl.com.ar","subject":"Re: git and unicode","fromName":"Remi Vanicat","fromEmail":"vanicat@debian.org","sentAt":"2008-01-08T15:09:35Z","receivedAt":"2008-01-08T15:09:35Z","isPatch":false,"sender":{"key":"vanicat@debian.org","avatar":"https://gravatar.com/avatar/cd491a7f4c221349809a60f88fc21326b97cce2a705e318898aa74851db92409?d=mp&s=160"},"body":"Gonzalo Garramuño writes:\n\n> Forking a little from the recent CR/LF thread, I was wondering how\n> does git deal with unicode files?\n>\n> Most scripting languages (ruby, python, etc) are now allowing their\n> source code to be written in unicode (UTF-8, usually). Will git\n> incorrectly categorize those source files as \"binary\"?\n>\n>\n> -- \n> Gonzalo Garramuño\n> ggarra@advancedsl.com.ar\n>\n> AMD4400 - ASUS48N-E\n> GeForce7300GT\n> Xubuntu Gutsy\n\n-- \nRémi Vanicat\n"},{"id":"64745","messageId":"Pine.LNX.4.64.0801081618311.25629@ds9.cixit.se","threadId":"11505","inReplyTo":"eaa105840801080507j1b748fy6fdff8b240cf8c33@mail.gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2008-01-08T15:20:09Z","receivedAt":"2008-01-08T15:20:09Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Peter Harris:\n\n> Actually, Subversion does the Right Thing, and treats everything as a\n> binary file until and unless you explicitly set the svn:eol-style\n> property on each file that you want it to mangle.\n> \n> Maybe you set up Subversion auto-props and forgot about it? That would\n> be almost (but not really) like setting autocrlf=true in your global\n> git config.\n\nActually, I've never actively set up a Subversion server myself, nor\ncreated any projects in Subversion (I have checked out some Subversion\nrepos, though). I started using RCS and CVS, and now I'm migrating at\nleast parts of that to Git (not all). Since Git is better than CVS in\nmany ways, I would like it to be better than CVS in this one as well.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"64746","messageId":"94ccbe710801080758s5913a3b8x4e17dfba1a5bc387@mail.gmail.com","threadId":"11505","inReplyTo":"eaa105840801080507j1b748fy6fdff8b240cf8c33@mail.gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Kelvie Wong","fromEmail":"kelvie@ieee.org","sentAt":"2008-01-08T15:58:35Z","receivedAt":"2008-01-08T15:58:35Z","isPatch":false,"sender":{"key":"kelvie@ieee.org","avatar":null},"body":"On Jan 8, 2008 5:07 AM, Peter Harris wrote:\n> On Jan 8, 2008 5:56 AM, Peter Karlsson wrote:\n> > Thomas Neumann:\n> >\n> > > as a user, I expect a SCM to only modify a file when I have\n> > > explicitly asked it to do so.\n> >\n> > As a user, I exepect things to just work. With RCS/CVS/Subversion, it\n> > does, because it differentiates between text files (internally encoding\n> > NLs with \"LF\", but I couldn't care less what it uses there) and binary\n> > files (which it doesn't change). With git it currently doesn't since it\n> > treats everything as binary files.\n>\n> Actually, Subversion does the Right Thing, and treats everything as a\n> binary file until and unless you explicitly set the svn:eol-style\n> property on each file that you want it to mangle.\n>\n> Maybe you set up Subversion auto-props and forgot about it? That would\n> be almost (but not really) like setting autocrlf=true in your global\n> git config.\n>\n> Peter Harris\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\nI'd actually like a feature like this. On the internal subversion\ntree I'm working on (using git-svn), there are quite a bit of files\nthat have CRLF endings -- we are a cross platform development group.\nThe solution to this in subversion was that everyone had the same\n.subversion/config with a bunch of autoprops set; i.e.:\n\n[auto-props]\n*.H = svn:eol-style=native\n*.h = svn:eol-style=native\n*.CPP = svn:eol-style=native\n*.cpp = svn:eol-style=native\n\nand I can't do the same using git-svn. Thankfully emacs detects CRLFs\nand adjusts accordingly, and that's my workaround for it, but it would\nbe nice to have some kind of gitattribute that allows you to set the\nautocrlf according to a filter.\n\n-- \nKelvie Wong\n"},{"id":"64755","messageId":"20080108172957.GG22155@fieldses.org","threadId":"11505","inReplyTo":"3B08AC4C-A807-4155-8AD7-DC6A6D0FE134-wjoc1KHpMeg@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"J. Bruce Fields","fromEmail":"bfields-uc3wqj2krung9huczpvpmw@public.gmane.org","sentAt":"2008-01-08T17:29:57Z","receivedAt":"2008-01-08T17:29:57Z","isPatch":false,"sender":{"key":"bfields-uc3wqj2krung9huczpvpmw@public.gmane.org","avatar":null},"body":"\nOn Mon, Jan 07, 2008 at 10:40:56PM +0100, Steffen Prohaska wrote:\n> Eventually I gave in and even voted for \"Git does not modify\n> content unless explicitly requested otherwise\".\n> \n> Here's the full discussion:\n> \n> http://code.google.com/p/msysgit/issues/detail?id=21\n> \n> I believe the main question is which type of projects we would like\n> to support by our default. For real cross-platform projects that will\n> be checked out on Windows and Unix we should choose\n> \"core.autocrlf true\" as our default. But if our default are native\n> Windows projects that will never be checked out on Unix, then we\n> should not set core.autocrlf by default.\n\nIf the policy really depends on the project, then surely the default\nbehavior should be determined by information carried in the project\nitself (e.g., the .gitattributes)?\n\nFor that reason it strikes me as a mistake to ignore the crlf attribute\nby default (assuming that is indeed the current behavior; apologies for\nnot checking). If crlf is set then I think it should be assumed that\ncrlf conversion should be done unless that has been explicitly turned\noff somehow.\n\n--b.\n"},{"id":"64759","messageId":"CE10C08D-AAF1-44B5-89B5-9A16A4AB70EA@zib.de","threadId":"11505","inReplyTo":"20080108172957.GG22155-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska-wjoc1khpmeg@public.gmane.org","sentAt":"2008-01-08T17:56:28Z","receivedAt":"2008-01-08T17:56:28Z","isPatch":false,"sender":{"key":"prohaska-wjoc1khpmeg@public.gmane.org","avatar":null},"body":"\n\nOn Jan 8, 2008, at 6:29 PM, J. Bruce Fields wrote:\n\n> On Mon, Jan 07, 2008 at 10:40:56PM +0100, Steffen Prohaska wrote:\n>> Eventually I gave in and even voted for \"Git does not modify\n>> content unless explicitly requested otherwise\".\n>>\n>> Here's the full discussion:\n>>\n>> http://code.google.com/p/msysgit/issues/detail?id=21\n>>\n>> I believe the main question is which type of projects we would like\n>> to support by our default. For real cross-platform projects that \n>> will\n>> be checked out on Windows and Unix we should choose\n>> \"core.autocrlf true\" as our default. But if our default are native\n>> Windows projects that will never be checked out on Unix, then we\n>> should not set core.autocrlf by default.\n>\n> If the policy really depends on the project, then surely the default\n> behavior should be determined by information carried in the project\n> itself (e.g., the .gitattributes)?\n\nUnfortunately it depends on the project _and_ the platform. A\ncross-platform project should have core.autocrlf=input on Unix and\ncore.autocrlf=true on Windows. I don't think I can represent this\nwith the current .gitattributes.\n\nDo you suggest to add this kind of magic to .gitattributes? Such as\nto have .gitattributes containing\n\n--- SNIP ---\n* crlf=autonative\n--- SNIP ---\n\nwhich would tell git to act as if core.autocrlf=input was set on Unix\nand core.autocrlf=true was set on Windows.\n\n\n> For that reason it strikes me as a mistake to ignore the crlf \n> attribute\n> by default (assuming that is indeed the current behavior; apologies \n> for\n> not checking). If crlf is set then I think it should be assumed that\n> crlf conversion should be done unless that has been explicitly turned\n> off somehow.\n\nI don't understand this comment.\n\nmsysgit installs plain git. core.autocrlf is unset. Whatever plain\ngit's default is, this is msysgit's default, too.\n\n\tSteffen\n"},{"id":"64761","messageId":"7vmyrgry20.fsf__36597.5010129206$1199815980$gmane$org@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"CE10C08D-AAF1-44B5-89B5-9A16A4AB70EA@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-08T18:07:19Z","receivedAt":"2008-01-08T18:07:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\n\nSteffen Prohaska writes:\n\n> msysgit installs plain git. core.autocrlf is unset. Whatever plain\n> git's default is, this is msysgit's default, too.\n\nThat sounds like a mistake if you are installing a port to a\nplatform whose native line ending convention is different from\nwhere plain git natively runs on (i.e. UNIX).\n"},{"id":"299028","messageId":"7vmyrgry20.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"CE10C08D-AAF1-44B5-89B5-9A16A4AB70EA@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-08T18:07:19Z","receivedAt":"2008-01-08T18:07:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\n\nSteffen Prohaska writes:\n\n> msysgit installs plain git. core.autocrlf is unset. Whatever plain\n> git's default is, this is msysgit's default, too.\n\nThat sounds like a mistake if you are installing a port to a\nplatform whose native line ending convention is different from\nwhere plain git natively runs on (i.e. UNIX).\n\n"},{"id":"64764","messageId":"02DC77F5-7465-418D-972E-0F76E56C3F75@zib.de","threadId":"11505","inReplyTo":"7vmyrgry20.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska-wjoc1khpmeg@public.gmane.org","sentAt":"2008-01-08T18:58:57Z","receivedAt":"2008-01-08T18:58:57Z","isPatch":false,"sender":{"key":"prohaska-wjoc1khpmeg@public.gmane.org","avatar":null},"body":"\n\nOn Jan 8, 2008, at 7:07 PM, Junio C Hamano wrote:\n\n>\n>\n> Steffen Prohaska writes:\n>\n>> msysgit installs plain git. core.autocrlf is unset. Whatever plain\n>> git's default is, this is msysgit's default, too.\n>\n> That sounds like a mistake if you are installing a port to a\n> platform whose native line ending convention is different from\n> where plain git natively runs on (i.e. UNIX).\n\nWe failed to agree on a better default and as the lengthy\ndiscussion documents, the best default isn't obvious.\n\nI don't think a solution will be found by declaring one platform\nnative (UNIX) and all other platform non-native. The question to\nanswer is how to support cross-platform projects. A valid\nsolution should never corrupt data unless the user explicitly\ntold git to do so. I don't believe it is a valid solution to set\ncore.autocrlf=true on Windows and tell the users: \"Well, in its\ndefault settings, git sometimes corrupts your data on Windows.\nMaybe you want to switch to Linux because this is the native\nplatform where data corruption will never happen.\"\n\nI'd prefer the \"warn/fail\" proposal.\n\n\tSteffen\n"},{"id":"64765","messageId":"20080108190952.GK22155@fieldses.org","threadId":"11505","inReplyTo":"02DC77F5-7465-418D-972E-0F76E56C3F75@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2008-01-08T19:09:52Z","receivedAt":"2008-01-08T19:09:52Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:\n>\n> On Jan 8, 2008, at 7:07 PM, Junio C Hamano wrote:\n>\n>>\n>>\n>> Steffen Prohaska writes:\n>>\n>>> msysgit installs plain git. core.autocrlf is unset. Whatever plain\n>>> git's default is, this is msysgit's default, too.\n>>\n>> That sounds like a mistake if you are installing a port to a\n>> platform whose native line ending convention is different from\n>> where plain git natively runs on (i.e. UNIX).\n>\n> We failed to agree on a better default and as the lengthy\n> discussion documents, the best default isn't obvious.\n>\n> I don't think a solution will be found by declaring one platform\n> native (UNIX) and all other platform non-native. The question to\n> answer is how to support cross-platform projects. A valid\n> solution should never corrupt data unless the user explicitly\n> told git to do so.\n\nMy only suggestion is that we consider allowing the user that\n\"explicitly told git to do so\" be the project maintainer. So if you\n\n\techo * autodetectcrlf >.gitattributes\n\tgit add .gitattributes\n\tgit commit\n\nthen users that clone your repo will get that default without having to\nbe told to do something magic on clone.\n\n(And ideally I'd've hoped you could do that using the existing crlf\nattribute rather than having to invent something new, but maybe that\ndoesn't work.)\n\n--b.\n\n> I don't believe it is a valid solution to set\n> core.autocrlf=true on Windows and tell the users: \"Well, in its\n> default settings, git sometimes corrupts your data on Windows.\n> Maybe you want to switch to Linux because this is the native\n> platform where data corruption will never happen.\"\n>\n> I'd prefer the \"warn/fail\" proposal.\n>\n> \tSteffen\n"},{"id":"64766","messageId":"7vir24rtfp.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"20080108190952.GK22155@fieldses.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-08T19:47:06Z","receivedAt":"2008-01-08T19:47:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:\n>> ...\n>> I don't think a solution will be found by declaring one platform\n>> native (UNIX) and all other platform non-native. The question to\n>> answer is how to support cross-platform projects. A valid\n>> solution should never corrupt data unless the user explicitly\n>> told git to do so.\n>\n> My only suggestion is that we consider allowing the user that\n> \"explicitly told git to do so\" be the project maintainer. So if you\n>\n> \techo * autodetectcrlf >.gitattributes\n> \tgit add .gitattributes\n> \tgit commit\n>\n> then users that clone your repo will get that default without having to\n> be told to do something magic on clone.\n>\n> (And ideally I'd've hoped you could do that using the existing crlf\n> attribute rather than having to invent something new, but maybe that\n> doesn't work.)\n\nI think the project can mark text files as text with attributes\nand if the port to the platform initialized core.autocrlf\nappropriately for the platform everything should work as you\ndescribed. \n\nAt least that is how I read the description of `crlf` in\ngitattributes(5).\n"},{"id":"64768","messageId":"E8DD3CE1-F59A-457F-B6D4-23DF7AEAF962@zib.de","threadId":"11505","inReplyTo":"20080108190952.GK22155@fieldses.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-08T19:59:46Z","receivedAt":"2008-01-08T19:59:46Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 8, 2008, at 8:09 PM, J. Bruce Fields wrote:\n\n> On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:\n>>\n>> On Jan 8, 2008, at 7:07 PM, Junio C Hamano wrote:\n>>\n>>>\n>>>\n>>> Steffen Prohaska writes:\n>>>\n>>>> msysgit installs plain git. core.autocrlf is unset. Whatever \n>>>> plain\n>>>> git's default is, this is msysgit's default, too.\n>>>\n>>> That sounds like a mistake if you are installing a port to a\n>>> platform whose native line ending convention is different from\n>>> where plain git natively runs on (i.e. UNIX).\n>>\n>> We failed to agree on a better default and as the lengthy\n>> discussion documents, the best default isn't obvious.\n>>\n>> I don't think a solution will be found by declaring one platform\n>> native (UNIX) and all other platform non-native. The question to\n>> answer is how to support cross-platform projects. A valid\n>> solution should never corrupt data unless the user explicitly\n>> told git to do so.\n>\n> My only suggestion is that we consider allowing the user that\n> \"explicitly told git to do so\" be the project maintainer. So if you\n>\n> \techo * autodetectcrlf >.gitattributes\n> \tgit add .gitattributes\n> \tgit commit\n>\n> then users that clone your repo will get that default without \n> having to\n> be told to do something magic on clone.\n>\n> (And ideally I'd've hoped you could do that using the existing crlf\n> attribute rather than having to invent something new, but maybe that\n> doesn't work.)\n\nI like this idea.\n\nI think we need the following:\n - if \"autodetectcrlf\" is set, git should guarantee that files in\n the repository will always have LF-only. Otherwise the automatic\n conversion can't work.\n - git needs to support a way to select the preferred type of\n line endings based on the OS. Unix users want to see LF,\n while Windows users want to see CRLF for the same file.\n\nAnd we could implement it as follows:\n - We add a configuration variable that sets the preferred\n autocrlf conversion, for example core.defaultautocrlf.\n - We add a new string value \"defaultauto\" for crlf in .gitattributes.\n crlf=defaultauto is similar to setting crlf to \"Unspecified\", but\n also forces git to act as if core.autocrlf is set to\n $(core.defaultautocrlf). That means if the content looks like text\n it will be converted according to the local settings.\n - On Unix, core.defaultautocrlf defaults to \"input\".\n - On Windows, core.defaultautocrlf defaults to \"crlf\".\n\nThis added layer of indirection gives us what we need: The\nfile .gitattributes tells git to convert line endings; but the\ndetails of the conversion depend on the environment (OS or\nconfiguration).\n\n\tSteffen\n"},{"id":"64769","messageId":"B655B6FF-9377-434A-A979-2E758771B0FA@zib.de","threadId":"11505","inReplyTo":"7vir24rtfp.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska-wjoc1khpmeg@public.gmane.org","sentAt":"2008-01-08T20:02:07Z","receivedAt":"2008-01-08T20:02:07Z","isPatch":false,"sender":{"key":"prohaska-wjoc1khpmeg@public.gmane.org","avatar":null},"body":"\n\nOn Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:\n\n>\n> \"J. Bruce Fields\" writes:\n>\n>> On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:\n>>> ...\n>>> I don't think a solution will be found by declaring one platform\n>>> native (UNIX) and all other platform non-native. The question to\n>>> answer is how to support cross-platform projects. A valid\n>>> solution should never corrupt data unless the user explicitly\n>>> told git to do so.\n>>\n>> My only suggestion is that we consider allowing the user that\n>> \"explicitly told git to do so\" be the project maintainer. So if you\n>>\n>> \techo * autodetectcrlf >.gitattributes\n>> \tgit add .gitattributes\n>> \tgit commit\n>>\n>> then users that clone your repo will get that default without \n>> having to\n>> be told to do something magic on clone.\n>>\n>> (And ideally I'd've hoped you could do that using the existing crlf\n>> attribute rather than having to invent something new, but maybe that\n>> doesn't work.)\n>\n> I think the project can mark text files as text with attributes\n> and if the port to the platform initialized core.autocrlf\n> appropriately for the platform everything should work as you\n> described.\n>\n> At least that is how I read the description of `crlf` in\n> gitattributes(5).\n\n\nBut we do not want to mark a file as text but tell git to run its\nauto-detection and use the local default line endings. But for\ndifferent projects we do not even want to run the auto-detection,\nbut leave the files as is.\n\nSee my separate mail that I just sent before I read yours.\n\n\tSteffen\n"},{"id":"64770","messageId":"7vbq7wrsb6.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"02DC77F5-7465-418D-972E-0F76E56C3F75@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-08T20:11:25Z","receivedAt":"2008-01-08T20:11:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n\tBy the way, is it your setting that mangles people's\n\te-mail addresses? If it is, is it possible for you to\n\tconfigure it to stop doing that?\n\n> I don't think a solution will be found by declaring one platform\n> native (UNIX) and all other platform non-native. The question to\n> answer is how to support cross-platform projects. A valid\n> solution should never corrupt data unless the user explicitly\n> told git to do so.\n\nI realize I might have misunderstood your intention.\n\nI did not use the word \"native\" to mean \"native vs second class\ncitizen\". The \"native\" in my description should have said \"a\nplatform whose native line ending convention happens to match\nwhat the project chose to use as its canonical blob object\nrepresentation\". And on such a platform, there is no need to\nworry about accidental corruption because there is no autocrlf\ninvolved. I could have said \"lucky platform\" instead of\n\"native\".\n\nI have been assuming that both of us are assuming LF line ending\nis what a typical cross-platform project would pick as the\ncanonical blob object representation. If you are assuming CRLF\nline ending as the canonical blob object representation for\nprojects originating from Windows, UNIX is not native (or\n\"lucky\") in such a project. Of course, in such a project,\nsetting \"core.autocrlf = true\" is absolutely a wrong thing to do\non Windows. Perhaps you meant that, and I would agree with you.\n\nIn such a project, setting \"core.autocrlf = reversed\" (which\nwould convert work tree LF line endings to canonical CRLF when\ncreating a blob, but we currently do not support it) on UNIX\nwould become necessary, if you want the resulting mess to work\nreasonably without configuration.\n\nAs long as \"cross-platform\" needs to support checkouts on\nplatforms with different conventions, and if you do not give\nexplicit marking about the binariness, platforms that are not\n\"lucky\" needs to guess. The alternative is to check out\nverbatim and effectively get it all wrong, from the platform\nconvention's point of view.\n\nThere is no avoiding that.\n\nHOWEVER.\n\nIf you mean by \"cross platform project\" a project that picks LF\nline ending as the canonical representation, then you cannot\ndeny the fact that Windows is not \"lucky\" and without explicit\nmarking about the binariness, it needs to guess. Again, the\nalternative is to check out verbatim and get it all wrong.\n"},{"id":"64772","messageId":"7v3at8rs4b.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"B655B6FF-9377-434A-A979-2E758771B0FA-wjoc1KHpMeg@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster-e+axbwqsrlaavxtiumwx3w@public.gmane.org","sentAt":"2008-01-08T20:15:32Z","receivedAt":"2008-01-08T20:15:32Z","isPatch":false,"sender":{"key":"gitster-e+axbwqsrlaavxtiumwx3w@public.gmane.org","avatar":null},"body":"\nSteffen Prohaska writes:\n\n> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:\n>>\n>> \"J. Bruce Fields\" writes:\n>>\n>>> My only suggestion is that we consider allowing the user that\n>>> \"explicitly told git to do so\" be the project maintainer. So if you\n>>>\n>>> \techo * autodetectcrlf >.gitattributes\n>>> \tgit add .gitattributes\n>>> \tgit commit\n>>>\n>>> then users that clone your repo will get that default without\n>>> having to\n>>> be told to do something magic on clone.\n>>>\n>>> (And ideally I'd've hoped you could do that using the existing crlf\n>>> attribute rather than having to invent something new, but maybe that\n>>> doesn't work.)\n>>\n>> I think the project can mark text files as text with attributes\n>> and if the port to the platform initialized core.autocrlf\n>> appropriately for the platform everything should work as you\n>> described.\n>>\n>> At least that is how I read the description of `crlf` in\n>> gitattributes(5).\n>\n>\n> But we do not want to mark a file as text but tell git to run its\n> auto-detection and use the local default line endings.\n\nMy reading of the description of `crlf` in gitattributes(5) is:\n\n `crlf`\n ^^^^^^\n\n This attribute controls the line-ending convention.\n\n Set::\n\n Setting the `crlf` attribute on a path is meant to mark\n the path as a \"text\" file. 'core.autocrlf' conversion\n takes place without guessing the content type by\n inspection.\n\n\nNotice \"without guessing\".\n"},{"id":"64773","messageId":"E258DB7F-21BD-4432-88BD-43E52B4A226E@zib.de","threadId":"11505","inReplyTo":"7vbq7wrsb6.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska-wjoc1khpmeg@public.gmane.org","sentAt":"2008-01-08T20:20:24Z","receivedAt":"2008-01-08T20:20:24Z","isPatch":false,"sender":{"key":"prohaska-wjoc1khpmeg@public.gmane.org","avatar":null},"body":"\n\nOn Jan 8, 2008, at 9:11 PM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n> \tBy the way, is it your setting that mangles people's\n> \te-mail addresses? If it is, is it possible for you to\n> \tconfigure it to stop doing that?\n\nNo. I have no idea where these mangled addresses come from.\nI did never see such addresses before.\n\nI thought I replaced all the mangled addresses in my last reply.\n\nI this mail wrong, too?\n\n\tSteffen\n"},{"id":"64784","messageId":"200801082136.21513.robin.rosenberg.lists@dewire.com","threadId":"11505","inReplyTo":"47835A02.80404@advancedsl.com.ar","subject":"Re: git and unicode","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-01-08T20:36:21Z","receivedAt":"2008-01-08T20:36:21Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\nUTF-8: no\nUTF-16: yes (actually \"most likely\" yes)\n\n-- robin\n"},{"id":"64775","messageId":"FADDEA64-FFE7-4420-AC1F-19262F415BAF@zib.de","threadId":"11505","inReplyTo":"7v3at8rs4b.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska-wjoc1khpmeg@public.gmane.org","sentAt":"2008-01-08T20:39:51Z","receivedAt":"2008-01-08T20:39:51Z","isPatch":false,"sender":{"key":"prohaska-wjoc1khpmeg@public.gmane.org","avatar":null},"body":"\n\nOn Jan 8, 2008, at 9:15 PM, Junio C Hamano wrote:\n\n>\n> Steffen Prohaska writes:\n>\n>> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:\n>>>\n>>> \"J. Bruce Fields\" >> uC3wQj2KruNg9hUCZPvPmw-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:\n>>>\n>>>> My only suggestion is that we consider allowing the user that\n>>>> \"explicitly told git to do so\" be the project maintainer. So if \n>>>> you\n>>>>\n>>>> \techo * autodetectcrlf >.gitattributes\n>>>> \tgit add .gitattributes\n>>>> \tgit commit\n>>>>\n>>>> then users that clone your repo will get that default without\n>>>> having to\n>>>> be told to do something magic on clone.\n>>>>\n>>>> (And ideally I'd've hoped you could do that using the existing crlf\n>>>> attribute rather than having to invent something new, but maybe \n>>>> that\n>>>> doesn't work.)\n>>>\n>>> I think the project can mark text files as text with attributes\n>>> and if the port to the platform initialized core.autocrlf\n>>> appropriately for the platform everything should work as you\n>>> described.\n>>>\n>>> At least that is how I read the description of `crlf` in\n>>> gitattributes(5).\n>>\n>>\n>> But we do not want to mark a file as text but tell git to run its\n>> auto-detection and use the local default line endings.\n>\n> My reading of the description of `crlf` in gitattributes(5) is:\n>\n> `crlf`\n> ^^^^^^\n>\n> This attribute controls the line-ending convention.\n>\n> Set::\n>\n> Setting the `crlf` attribute on a path is meant to mark\n> the path as a \"text\" file. 'core.autocrlf' conversion\n> takes place without guessing the content type by\n> inspection.\n>\n>\n> Notice \"without guessing\".\n\nExactly this is the problem. Some projects want guessing. A\nproject needs to have a way to explicitly tell git that is should\nguess the file type and if it found \"text\", then it should use\nthe right line endings (that is the locally preferred endings).\nIf the project has control, the project maintainer is responsible\nfor making the right choice. That is either he enables automatic\ndetection of \"text\" files, or he can explicitly tell git about\nthe types without guessing.\n\nA different project may not want to have guessing at all, but\nleave all files as is. I believe this should be the default for\nall projects that do not explicitly choose otherwise. I'm still\nreluctant to enabling guessing as a system wide default. Someone\nmay just want to use git to manage a few binary files locally on\nhis machine. I'd be unhappy if \"guessing\" corrupted these files.\n\nThe project needs control if guessing is activated or not. Right\nnow we have no way for a project to tell git that it should\nguess, even if the default for other projects is not to guess.\n\n\tSteffen\n"},{"id":"64778","messageId":"alpine.LFD.1.00.0801081232120.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"7vir24rtfp.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org","sentAt":"2008-01-08T20:41:33Z","receivedAt":"2008-01-08T20:41:33Z","isPatch":false,"sender":{"key":"torvalds-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org","avatar":null},"body":"\n\n\nOn Tue, 8 Jan 2008, Junio C Hamano wrote:\n>\n> I think the project can mark text files as text with attributes\n> and if the port to the platform initialized core.autocrlf\n> appropriately for the platform everything should work as you\n> described. \n\nYes, I think core.autocrlf should default to \"true\" on Windows, since \nthat is what it's about. The alternative is to have \"fail\"/\"warn\", to just \nmake sure that nobody can do the wrong thing by mistake.\n\nWe could just do something like this, although that probably does mean \nthat the whole test-suite needs to be double-checked (ie now we really do \nbehave differently on windows outside of any config options!))\n\nPeople who really dislike it can always do the\n\n\tgit config --global core.autocrlf false\n\nthing.\n\n(And no, I don't know if \"#ifdef __WINDOWS__\" is the right thing to do, \nit's almost certainly not. This is just a draft.)\n\n\t\tLinus\n\n---\n environment.c | 16 +++++++++++++++-\n 1 files changed, 15 insertions(+), 1 deletions(-)\n\ndiff --git a/environment.c b/environment.c\nindex 18a1c4e..5766bee 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -34,9 +34,23 @@ char *pager_program;\n int pager_use_color = 1;\n char *editor_program;\n char *excludes_file;\n-int auto_crlf = 0;\t/* 1: both ways, -1: only when adding git objects */\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n \n+/*\n+ * Automatic CRLF conversion on files that look like\n+ * text:\n+ * 0: none (unix)\n+ * 1: convert to LF on check-in and to CRLF on check-out\n+ * -1: only on check-in (check-out with just LF)\n+ */\n+#ifdef __WINDOWS__\n+ #define DEF_AUTOCRLF 1\n+#else\n+ #define DEF_AUTOCRLF 0\n+#endif\n+\n+int auto_crlf = DEF_AUTOCRLF;\n+\n /* This is set by setup_git_dir_gently() and/or git_default_config() */\n char *git_work_tree_cfg;\n static const char *work_tree;\n"},{"id":"64780","messageId":"20080108205054.GN6951@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"02DC77F5-7465-418D-972E-0F76E56C3F75@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-08T20:50:54Z","receivedAt":"2008-01-08T20:50:54Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:\n> \n> I don't think a solution will be found by declaring one platform\n> native (UNIX) and all other platform non-native. The question to\n> answer is how to support cross-platform projects. A valid\n> solution should never corrupt data unless the user explicitly\n> told git to do so. I don't believe it is a valid solution to set\n> core.autocrlf=true on Windows and tell the users: \"Well, in its\n> default settings, git sometimes corrupts your data on Windows.\n> Maybe you want to switch to Linux because this is the native\n> platform where data corruption will never happen.\"\n\nMaybe I am wrong but it seems to me that to guarantee that\nCRLF conversion is reversible (which means that you can\nalways get exactly what you put into the repository), it is\nenough to check that the conversation is performed only if\nevery LF is preceded by CR. If it is not so, error out and\ntell the user that the file should be either marked as binary\nor EOL in the text must be corrected.\n\nSo, even in those rare cases where the heuristic went wrong,\nyou will not lose your data. Most likely you will get the\nabove error, but even if a binary file is checked in as text,\nit will affect only cross-platform projects, and it will be\neasily to correct the situation later by marking this file\nas binary and checking in again. So, it is a extermely rare\nevent, and no data is lost.\n\nPerhaps, this option can be called core.autocrlf=safe\n\nIMHO, a _text_ file is not just some octets, it consists of\nlines. Even without CRLF conversation, Git is aware about\nto do some basic operations like diff and merge. So, it is\nnatural to store lines in the repository in the same EOL\nmarker regardless on what platform the file is created. So,\nhaving core.autocrlf=false on Windows is wrong. You may not\nnotice it until you do not move to another platform, but the\nwhole thing is already broken. It is not about one platform\nbeing more native than other. It is like in the C standard,\nLF is used to denote the end of line, because it is the only\nsane choice to mark it.\n\nDmitry\n"},{"id":"64783","messageId":"7vy7b0qarq.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"20080108205054.GN6951-EQL4cN526mwi5CQI31g/s0B+6BGkLq7r@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster-e+axbwqsrlaavxtiumwx3w@public.gmane.org","sentAt":"2008-01-08T21:15:37Z","receivedAt":"2008-01-08T21:15:37Z","isPatch":false,"sender":{"key":"gitster-e+axbwqsrlaavxtiumwx3w@public.gmane.org","avatar":null},"body":"\nDmitry Potapov writes:\n\n> On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:\n>> \n>> I don't think a solution will be found by declaring one platform\n>> native (UNIX) and all other platform non-native. The question to\n>> answer is how to support cross-platform projects. A valid\n>> solution should never corrupt data unless the user explicitly\n>> told git to do so. I don't believe it is a valid solution to set\n>> core.autocrlf=true on Windows and tell the users: \"Well, in its\n>> default settings, git sometimes corrupts your data on Windows.\n>> Maybe you want to switch to Linux because this is the native\n>> platform where data corruption will never happen.\"\n>\n> Maybe I am wrong but it seems to me that to guarantee that\n> CRLF conversion is reversible (which means that you can\n> always get exactly what you put into the repository), it is\n> enough to check that the conversation is performed only if\n> every LF is preceded by CR.\n\nI've heard that before but I seem to recall convert.c already\ndoing something similar if I am not mistaken.\n\nstatic int crlf_to_git(const char *path, const char *src, size_t len,\n struct strbuf *buf, int action)\n{\n\tstruct text_stat stats;\n\tchar *dst;\n\n\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n\t\treturn 0;\n\n\tgather_stats(src, len, &stats);\n\t/* No CR? Nothing to convert, regardless. */\n\tif (!stats.cr)\n\t\treturn 0;\n\n\tif (action == CRLF_GUESS) {\n\t\t/*\n\t\t * We're currently not going to even try to convert stuff\n\t\t * that has bare CR characters. Does anybody do that crazy\n\t\t * stuff?\n\t\t */\n\t\tif (stats.cr != stats.crlf)\n\t\t\treturn 0;\n\n\t\t/*\n\t\t * And add some heuristics for binary vs text, of course...\n\t\t */\n\t\tif (is_binary(len, &stats))\n\t\t\treturn 0;\n\t}\n\nIt counts CR and CRLF and converts only when there are the same\nnumber of them. You probably only need to make it also count\nLF?\n"},{"id":"64792","messageId":"alpine.DEB.1.00.0801082226110.21686@perkele.intern.softwolves.pp.se","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801071332530.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2008-01-08T21:26:53Z","receivedAt":"2008-01-08T21:26:53Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Linus Torvalds:\n\n> So defaulting to (or asking) \"autocrlf\" at install time is probably the \n> safest thing, and then people can edit their global .gitconfig to turn it \n> off.\n\nIndeed. A checkbox in the Windows installer (like Cygwin has) would be nice.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"64786","messageId":"alpine.LFD.1.00.0801081325010.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"20080108205054.GN6951-EQL4cN526mwi5CQI31g/s0B+6BGkLq7r@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org","sentAt":"2008-01-08T21:31:57Z","receivedAt":"2008-01-08T21:31:57Z","isPatch":false,"sender":{"key":"torvalds-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org","avatar":null},"body":"\n\n\nOn Tue, 8 Jan 2008, Dmitry Potapov wrote:\n> \n> Perhaps, this option can be called core.autocrlf=safe\n\nWe already do half of that:\n\n if (action == CRLF_GUESS) {\n /*\n * We're currently not going to even try to convert stuff\n * that has bare CR characters. Does anybody do that crazy\n * stuff?\n */\n if (stats.cr != stats.crlf)\n return 0;\n\nbut we don't check that there are no \"naked\" LF characters.\n\nSo the only thing you'd need to add is to add a\n\n\t\t/* No naked LF's! */\n\t\tif (safecrlf && stats.lf)\n\t\t\treturn 0;\n\nto that sequence too, but the thing is, having mixed line-endings isn't \nactually all that unusual, so I think that kind of \"autocrlf=safe\" thing \nis actually almost useless - because when that thing triggers, you almost \nalways *do* want to convert it to be just one way.\n\nI've seen it multiple times when people cooperate with windows files with \nunix tools, where unix editors often preserve old CRLF's, but write new \nlines with just LF.\n\nSo \"autocrlf=safe\" would be trivial to add, but I suspect it would cause \nmore confusion than it would fix.\n\n\t\tLinus\n"},{"id":"64785","messageId":"20080108213336.GO6951@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"eaa105840801080507j1b748fy6fdff8b240cf8c33@mail.gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-08T21:33:36Z","receivedAt":"2008-01-08T21:33:36Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Jan 08, 2008 at 08:07:15AM -0500, Peter Harris wrote:\n> \n> Actually, Subversion does the Right Thing, and treats everything as a\n> binary file until and unless you explicitly set the svn:eol-style\n> property on each file that you want it to mangle.\n\nNot exactly. Actually, Subversion detects binary or text file based\non heuristic. http://subversion.tigris.org/faq.html#binary-files\nBut the status of a file as binary or text has no effect whatsoever\non on CRLF conversation, which is controlled by another property.\nBy default, most of your text files will be detected as text (unless\nyou use non-ASCII character like Cyrillic), but they will not have\nCRLF conversation. Now, you have to set svn:eol-style=native for\neach new file, which of course can be done automatically based on\nfile extension, but that should be configured by each user in his\nor her global config file. Obviously, it does not work well for\ncross-platform projects, because many users forget to set\nsvn:eol-style=native for some extensions. Moreover, the issue tends\nto repeat itself for every newly introduced file extension...\n\nIMHO, having the binary or text status completely independent from\nCRLF conversation is insanity...\n\nDmitry\n"},{"id":"64787","messageId":"200801082257.05949.robin.rosenberg.lists@dewire.com","threadId":"11505","inReplyTo":"7vy7b0qarq.fsf@gitster.siamese.dyndns.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-01-08T21:57:04Z","receivedAt":"2008-01-08T21:57:04Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdagen den 8 januari 2008 skrev Junio C Hamano:\n> It counts CR and CRLF and converts only when there are the same\n> number of them. You probably only need to make it also count\n> LF?\n\nStrictly speaking yes, but probably no anyway. Some tools on Windows\nkeep existing line endings for existing lines but add CRLF for new ones.\nI can only think of one right now, but that's at least one.\n\n-- robin\n"},{"id":"64788","messageId":"BAYC1-PASMTP14154E8108546AB0F9457FAE480@CEZ.ICE","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801081325010.3148-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Sean","fromEmail":"seanlkml-riew9wucm8ffj04o6pk0fg@public.gmane.org","sentAt":"2008-01-08T22:09:44Z","receivedAt":"2008-01-08T22:09:44Z","isPatch":false,"sender":{"key":"seanlkml-riew9wucm8ffj04o6pk0fg@public.gmane.org","avatar":null},"body":"\nOn Tue, 8 Jan 2008 13:31:57 -0800 (PST)\nLinus Torvalds wrote:\n\n> So the only thing you'd need to add is to add a\n> \n> \t\t/* No naked LF's! */\n> \t\tif (safecrlf && stats.lf)\n> \t\t\treturn 0;\n> \n> to that sequence too, but the thing is, having mixed line-endings isn't \n> actually all that unusual, so I think that kind of \"autocrlf=safe\" thing \n> is actually almost useless - because when that thing triggers, you almost \n> always *do* want to convert it to be just one way.\n> \n> I've seen it multiple times when people cooperate with windows files with \n> unix tools, where unix editors often preserve old CRLF's, but write new \n> lines with just LF.\n> \n> So \"autocrlf=safe\" would be trivial to add, but I suspect it would cause \n> more confusion than it would fix.\n\nBut isn't the entire point of this exercise to ensure that you will never\nbe in the situation on Linux where you checkout files that have CRLF endings?\nAnd conversely that on Windows you will never checkout files that have LF\nendings? If so, you don't have to worry about your tools creating mixed\nending files.\n\nThe only time the above rules should be broken, is when the user explicitly\nstates that their tools will do-the-right-thing without such help.\n\nSean\n"},{"id":"64793","messageId":"20080108225138.GA23240@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801081325010.3148-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov-re5jqeeqqe8avxtiumwx3w@public.gmane.org","sentAt":"2008-01-08T22:51:38Z","receivedAt":"2008-01-08T22:51:38Z","isPatch":false,"sender":{"key":"dpotapov-re5jqeeqqe8avxtiumwx3w@public.gmane.org","avatar":null},"body":"\nOn Tue, Jan 08, 2008 at 01:31:57PM -0800, Linus Torvalds wrote:\n> \n> but we don't check that there are no \"naked\" LF characters.\n\nBut my idea was about checking for \"naked\" LF, because if there is at\nleast one naked LF, then you will get a _different_ file than you\nput into the repository.\n\n> \n> So the only thing you'd need to add is to add a\n> \n> \t\t/* No naked LF's! */\n> \t\tif (safecrlf && stats.lf)\n\nIt seems the check for named LF should be:\n\t\tif (safecrlf && stats.lf == stats.crlf)\n\n> \t\t\treturn 0;\n\nUnfortunately, you cannot return 0 here, because if there is\nno CRLF, the opposite conversation cannot tell apart when all\nCRLF were successfully converted to LF, and when there was no\nconversation at all. So, the only thing to do here is to die()\nsaying this file should be either marked as binary or EOL in\nthe text must be corrected.\n\n> \n> to that sequence too, but the thing is, having mixed line-endings isn't \n> actually all that unusual, so I think that kind of \"autocrlf=safe\" thing \n> is actually almost useless - because when that thing triggers, you almost \n> always *do* want to convert it to be just one way.\n\nI agree that in most cases, you *do* want to covert, but the idea of the\n\"safe\" mode is to protect you from the possibility (whatever small it\nis) when you do not want to convert, because it is a _binary_ file, but\nis_binary heuristic was wrong.\n\n> I've seen it multiple times when people cooperate with windows files with \n> unix tools, where unix editors often preserve old CRLF's, but write new \n> lines with just LF.\n> \n> So \"autocrlf=safe\" would be trivial to add, but I suspect it would cause \n> more confusion than it would fix.\n\nThe idea of \"autocrlf=safe\" is always to be on the safe side. Those who\nprefer automatic correction of EOL can use \"autocrlf=true\". Besides,\nchecking EOL is somewhat similar checking whitespaces. Git allows you\neither have --whitespace=error or --whitespace=strip, so it is reasonable\nto have the same choice about EOL. I may choose either the \"safe\" mode,\nwhich will only error out, or I can have the \"true\" mode, which corrects\nEOLs on-fly.\n\nDmitry\n"},{"id":"64798","messageId":"alpine.LFD.1.00.0801081601180.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"20080108225138.GA23240-EQL4cN526mwi5CQI31g/s0B+6BGkLq7r@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org","sentAt":"2008-01-09T00:01:58Z","receivedAt":"2008-01-09T00:01:58Z","isPatch":false,"sender":{"key":"torvalds-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org","avatar":null},"body":"\n\n\nOn Wed, 9 Jan 2008, Dmitry Potapov wrote:\n> \n> It seems the check for named LF should be:\n> \t\tif (safecrlf && stats.lf == stats.crlf)\n\nNo. If there was a crlf, then we won't increment the lf count.\n\n(Not that I tested it, but that's how it was supposed to work)\n\n\t\tLinus\n"},{"id":"64821","messageId":"7vd4sbmnmz.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801081232120.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-09T08:03:32Z","receivedAt":"2008-01-09T08:03:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 8 Jan 2008, Junio C Hamano wrote:\n>>\n>> I think the project can mark text files as text with attributes\n>> and if the port to the platform initialized core.autocrlf\n>> appropriately for the platform everything should work as you\n>> described. \n>\n> Yes, I think core.autocrlf should default to \"true\" on Windows, since \n> that is what it's about. The alternative is to have \"fail\"/\"warn\", to just \n> make sure that nobody can do the wrong thing by mistake.\n>\n> We could just do something like this, although that probably does mean \n> that the whole test-suite needs to be double-checked (ie now we really do \n> behave differently on windows outside of any config options!))\n>\n> People who really dislike it can always do the\n>\n> \tgit config --global core.autocrlf false\n>\n> thing.\n>\n> (And no, I don't know if \"#ifdef __WINDOWS__\" is the right thing to do, \n> it's almost certainly not. This is just a draft.)\n\nPerhaps we can do something similar to core.filemode? Create a\nfile that we would need to create anyway in \"text\" mode, and\nread it back in \"binary\" mode to see what stdio did?\n"},{"id":"64829","messageId":"fm21f2$18e$1@ger.gmane.org","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801081325010.3148-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Abdelrazak Younes","fromEmail":"younes.a-ganu6spqydw@public.gmane.org","sentAt":"2008-01-09T08:43:12Z","receivedAt":"2008-01-09T08:43:12Z","isPatch":false,"sender":{"key":"younes.a-ganu6spqydw@public.gmane.org","avatar":null},"body":"\nLinus Torvalds wrote:\n> \n> \n> On Tue, 8 Jan 2008, Dmitry Potapov wrote:\n>> Perhaps, this option can be called core.autocrlf=safe\n> \n> We already do half of that:\n> \n> if (action == CRLF_GUESS) {\n> /*\n> * We're currently not going to even try to convert stuff\n> * that has bare CR characters. Does anybody do that crazy\n> * stuff?\n> */\n> if (stats.cr != stats.crlf)\n> return 0;\n> \n> but we don't check that there are no \"naked\" LF characters.\n> \n> So the only thing you'd need to add is to add a\n> \n> \t\t/* No naked LF's! */\n> \t\tif (safecrlf && stats.lf)\n> \t\t\treturn 0;\n> \n> to that sequence too, but the thing is, having mixed line-endings isn't \n> actually all that unusual, so I think that kind of \"autocrlf=safe\" thing \n> is actually almost useless - because when that thing triggers, you almost \n> always *do* want to convert it to be just one way.\n\nSorry for the irruption in this discussion but as a potential git user \nfor cross-platform development I'd like to share my experience/opinion, \nhope you don't mind.\n\nI am investigating the use of git for our cross-platform project which \nuses svn currently. In our project, we mark manually *all* source file \n(*.h and *.cpp) with 'eol-style=native'. This way, if some editor on \nWindows added some CRLF in such marked file, svn will refuse to commit \nthis file until you clean it up. This means that all C/C++/python files \nuses LF eol exclusively on all platforms. I believe this is the only \nsane way to do cross-platform development.\n\nNow, marking any new file manually is cumbersome and some developers \noften forget to do it. I would like to be able mark all files with a \ngiven extension (.c, .cpp, .h) with \"LF only\". This way, Windows only \nfiles (like visual studio projects) can stay with CRLF. It would be \nfantastic if git could do that.\n\n> \n> I've seen it multiple times when people cooperate with windows files with \n> unix tools, where unix editors often preserve old CRLF's, but write new \n> lines with just LF.\n\nMultiple versions of Visual studio do just this indeed.\n\nAbdel.\n"},{"id":"64840","messageId":"alpine.LSU.1.00.0801091041570.31053@racer.site","threadId":"11505","inReplyTo":"7vd4sbmnmz.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","sentAt":"2008-01-09T10:48:47Z","receivedAt":"2008-01-09T10:48:47Z","isPatch":false,"sender":{"key":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","avatar":null},"body":"\nHi,\n\nOn Wed, 9 Jan 2008, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > On Tue, 8 Jan 2008, Junio C Hamano wrote:\n> >>\n> >> I think the project can mark text files as text with attributes and \n> >> if the port to the platform initialized core.autocrlf appropriately \n> >> for the platform everything should work as you described.\n> >\n> > Yes, I think core.autocrlf should default to \"true\" on Windows, since \n> > that is what it's about. The alternative is to have \"fail\"/\"warn\", to \n> > just make sure that nobody can do the wrong thing by mistake.\n> >\n> > We could just do something like this, although that probably does mean \n> > that the whole test-suite needs to be double-checked (ie now we really \n> > do behave differently on windows outside of any config options!))\n> >\n> > People who really dislike it can always do the\n> >\n> > \tgit config --global core.autocrlf false\n> >\n> > thing.\n> >\n> > (And no, I don't know if \"#ifdef __WINDOWS__\" is the right thing to \n> > do, it's almost certainly not. This is just a draft.)\n\nIMHO this is really not good. Better do it in the global /etc/gitconfig \nwe install _anyway_ (it says core.symlinks=false).\n\n> Perhaps we can do something similar to core.filemode? Create a file \n> that we would need to create anyway in \"text\" mode, and read it back in \n> \"binary\" mode to see what stdio did?\n\nThe problem is that MinGW behaves sanely, i.e. it does not output CRLF but \nonly LF.\n\nBesides, as I stated several times already, there _are_ projects on \nWindows where you do _not_ want crlf=true:\n\n- Windows is already slow. So slow that it is not even funny. Granted, \n if you use Windows daily, git on MinGW seems snappy, but if you come \n from Linux, it is slow as hell.\n\n And CRLF conversion does not help that impression at all.\n\n- Some tools ported to Windows from Unix do not like CRs.\n\n- For git itself, I prefer to work without CRLF just because I do not need \n it.\n\nBut maybe I am the minority here, and we really should default to \ncrlf=true on Windows, and provide a way to unset that.\n\nMy preference would be to have Peff's -c switch to clone, but \n_additionally_ a way to force a full re-checkout of files (for example \nafter \"git config core.crlf false\").\n\nCiao,\nDscho\n"},{"id":"64841","messageId":"alpine.LSU.1.00.0801091054400.31053@racer.site","threadId":"11505","inReplyTo":"alpine.DEB.1.00.0801082226110.21686@perkele.intern.softwolves.pp.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-09T10:56:30Z","receivedAt":"2008-01-09T10:56:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 8 Jan 2008, Peter Karlsson wrote:\n\n> Linus Torvalds:\n> \n> > So defaulting to (or asking) \"autocrlf\" at install time is probably \n> > the safest thing, and then people can edit their global .gitconfig to \n> > turn it off.\n> \n> Indeed. A checkbox in the Windows installer (like Cygwin has) would be \n> nice.\n\nNo. There are different needs for different projects, and having \ndifferent defaults just adds to the confusion.\n\nI am no longer opposed to setting crlf=true by default for Git (although \nthis does not necessarily hold true for msysGit, but that could be \nhelped by explicitely unsetting crlf for the repositories we check out \nwith the netinstaller).\n\nCiao,\nDscho\n"},{"id":"64842","messageId":"alpine.LSU.1.00.0801091100401.31053@racer.site","threadId":"11505","inReplyTo":"B655B6FF-9377-434A-A979-2E758771B0FA-wjoc1KHpMeg@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","sentAt":"2008-01-09T11:03:30Z","receivedAt":"2008-01-09T11:03:30Z","isPatch":false,"sender":{"key":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","avatar":null},"body":"\nHi,\n\nOn Tue, 8 Jan 2008, Steffen Prohaska wrote:\n\n> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:\n> \n> > I think the project can mark text files as text with attributes and if \n> > the port to the platform initialized core.autocrlf appropriately for \n> > the platform everything should work as you described.\n> > \n> > At least that is how I read the description of `crlf` in \n> > gitattributes(5).\n> \n> But we do not want to mark a file as text but tell git to run its \n> auto-detection and use the local default line endings. But for \n> different projects we do not even want to run the auto-detection, but \n> leave the files as is.\n\nProbably the best thing would be to default to crlf=true, and then have a \n.gitattributes file like this in your project:\n\n-- snip --\n*.am -crlf\n-- snap --\n\n(Did I guess right about the file extension? But why do you want to check \nin huge 3D stacks? Ah, of course, for test cases.)\n\nCiao,\nDscho\n"},{"id":"64845","messageId":"04EF2652-9AA8-4976-903F-DBE4E7AA13D7@zib.de","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801091054400.31053@racer.site","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-09T12:41:38Z","receivedAt":"2008-01-09T12:41:38Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 9, 2008, at 11:56 AM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Tue, 8 Jan 2008, Peter Karlsson wrote:\n>\n>> Linus Torvalds:\n>>\n>>> So defaulting to (or asking) \"autocrlf\" at install time is probably\n>>> the safest thing, and then people can edit their \n>>> global .gitconfig to\n>>> turn it off.\n>>\n>> Indeed. A checkbox in the Windows installer (like Cygwin has) \n>> would be\n>> nice.\n>\n> No. There are different needs for different projects, and having\n> different defaults just adds to the confusion.\n>\n> I am no longer opposed to setting crlf=true by default for Git \n> (although\n> this does not necessarily hold true for msysGit, but that could be\n> helped by explicitely unsetting crlf for the repositories we check out\n> with the netinstaller).\n\nI'll further think about \"crlf=safe\" (see another mail in this\nthread). I like the idea of safe because it guarantees that data\nwill never be corrupted. But I have no time to think about it\nimmediately.\n\n\tSteffen\n"},{"id":"64846","messageId":"019B1C82-27BF-4B6B-981D-5498D31B5DD3@zib.de","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801091100401.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska-wjoc1khpmeg@public.gmane.org","sentAt":"2008-01-09T12:45:38Z","receivedAt":"2008-01-09T12:45:38Z","isPatch":false,"sender":{"key":"prohaska-wjoc1khpmeg@public.gmane.org","avatar":null},"body":"\n\nOn Jan 9, 2008, at 12:03 PM, Johannes Schindelin wrote:\n\n> On Tue, 8 Jan 2008, Steffen Prohaska wrote:\n>\n>> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:\n>>\n>>> I think the project can mark text files as text with attributes \n>>> and if\n>>> the port to the platform initialized core.autocrlf appropriately for\n>>> the platform everything should work as you described.\n>>>\n>>> At least that is how I read the description of `crlf` in\n>>> gitattributes(5).\n>>\n>> But we do not want to mark a file as text but tell git to run its\n>> auto-detection and use the local default line endings. But for\n>> different projects we do not even want to run the auto-detection, but\n>> leave the files as is.\n>\n> Probably the best thing would be to default to crlf=true, and then \n> have a\n> .gitattributes file like this in your project:\n>\n> -- snip --\n> *.am -crlf\n> -- snap --\n>\n> (Did I guess right about the file extension? But why do you want to \n> check\n> in huge 3D stacks? Ah, of course, for test cases.)\n\nYes, thanks ;)\n\nFor now, this is the right thing to do. However, our file format\nand the application does not depend on the extension. A a long\nterm solution, I'll fix our file format header to include '\\0' if\nthe file is binary.\n\n\tSteffen\n"},{"id":"64849","messageId":"alpine.LSU.1.00.0801091330340.31053@racer.site","threadId":"11505","inReplyTo":"019B1C82-27BF-4B6B-981D-5498D31B5DD3-wjoc1KHpMeg@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","sentAt":"2008-01-09T13:32:04Z","receivedAt":"2008-01-09T13:32:04Z","isPatch":false,"sender":{"key":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","avatar":null},"body":"\nHi,\n\nOn Wed, 9 Jan 2008, Steffen Prohaska wrote:\n\n> On Jan 9, 2008, at 12:03 PM, Johannes Schindelin wrote:\n> \n> > -- snip --\n> > *.am -crlf\n> > -- snap --\n> > \n> > (Did I guess right about the file extension? But why do you want to \n> > check in huge 3D stacks? Ah, of course, for test cases.)\n> \n> Yes, thanks ;)\n> \n> For now, this is the right thing to do. However, our file format and \n> the application does not depend on the extension. A a long term \n> solution, I'll fix our file format header to include '\\0' if the file is \n> binary.\n\nOf course, that would help the binary detection of both subversion and \ngit, but it would break 3rd party readers of the format :-(\n\nThanks for the heads-up,\nDscho\n"},{"id":"64852","messageId":"C3AA823B.10C50%jefferis@gmail.com","threadId":"11505","inReplyTo":"04EF2652-9AA8-4976-903F-DBE4E7AA13D7@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Gregory Jefferis","fromEmail":"jefferis@gmail.com","sentAt":"2008-01-09T13:52:59Z","receivedAt":"2008-01-09T13:52:59Z","isPatch":false,"sender":{"key":"jefferis@gmail.com","avatar":"https://gravatar.com/avatar/8528f4e227ebc88380c203c816e263246064e31f6180681dc2c6dabfaff24d6b?d=mp&s=160"},"body":"On 9/1/08 12:41, \"Steffen Prohaska\" wrote:\n\n> I'll further think about \"crlf=safe\" (see another mail in this\n> thread). I like the idea of safe because it guarantees that data\n> will never be corrupted. But I have no time to think about it\n> immediately.\n\ncrlf=safe [i.e. munging CRLFs only if there are no bare LFs] sounds\nappealing to me as well because it looks like munging that is always\nreversible. However there could still be problems at checkout. To be\nreally safe, it seems to me that it must be 1) reversible in practice and 2)\nALWAYS reversed unless we explicitly ask for no gnuming at checkout. Why?\n\nRe point (1) to be reversible in practice, we need to know who we've munged.\nOtherwise when gnuming blindly at checkout we might damage some innocent\nbystander file that only ever had LFs in the first place. So it seems we\nwould have to keep track of who was munged. But do we want to store this in\nthe repository?\n\nRe (2) well if we happen to munge a file on checkin that is actually binary,\nit must be gnumed on the way out otherwise it will be broken for the user.\n"},{"id":"64853","messageId":"alpine.LSU.1.00.0801091401101.31053@racer.site","threadId":"11505","inReplyTo":"C3AA823B.10C50%jefferis@gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-09T14:03:32Z","receivedAt":"2008-01-09T14:03:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 9 Jan 2008, Gregory Jefferis wrote:\n\n> On 9/1/08 12:41, \"Steffen Prohaska\" wrote:\n> \n> > I'll further think about \"crlf=safe\" (see another mail in this \n> > thread). I like the idea of safe because it guarantees that data will \n> > never be corrupted. But I have no time to think about it immediately.\n> \n> crlf=safe [i.e. munging CRLFs only if there are no bare LFs] sounds \n> appealing to me as well because it looks like munging that is always \n> reversible.\n\nThere is a bigger problem here, though: As of now, you can add a (loose) \nobject from a big file pretty easily even on a small machine, because you \ndo not need the whole buffer, but you stream it to hash-object. IIRC \nJunio wrote a patch to allow this with \"git-add\", using fast-import, but \nthat patch probably hasn't been applied.\n\nCiao,\nDscho\n"},{"id":"64856","messageId":"20080109150310.GC23659@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"C3AA823B.10C50%jefferis@gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-09T15:03:10Z","receivedAt":"2008-01-09T15:03:10Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jan 09, 2008 at 01:52:59PM +0000, Gregory Jefferis wrote:\n> \n> crlf=safe [i.e. munging CRLFs only if there are no bare LFs] sounds\n> appealing to me as well because it looks like munging that is always\n> reversible. However there could still be problems at checkout. To be\n> really safe, it seems to me that it must be 1) reversible in practice and 2)\n> ALWAYS reversed unless we explicitly ask for no gnuming at checkout. Why?\n> \n> Re point (1) to be reversible in practice, we need to know who we've munged.\n> Otherwise when gnuming blindly at checkout we might damage some innocent\n> bystander file that only ever had LFs in the first place.\n\nIf you work on Windows and you have clrf=safe, you cannot put a text\nfile that has only LFs, because naked LF is not allowed. If you want\nto have naked LF in some file, you have to say that explicitly in\n.gitattributes.\n\nIf you work on cross platform project, and somebody else put a file with\nbare LFs, which is not text though heauristic wrongly detected it as\ntext then you can remove this file from your working directory, correct\n.gitattributes and checkout this file again. The idea of crlf=safe is\nthat information is never lost. It is always fully reversible, and if\nyou put something into the repostory, you always get back exactly the\nsame unless you changed your .gitattributes.\n\n> Re (2) well if we happen to munge a file on checkin that is actually binary,\n> it must be gnumed on the way out otherwise it will be broken for the user.\n\nOf course, it will, because the same heuristic will detect it as text,\nand convert it back. So as long as you stay on the same platform and\nwith the same .gitattributes, you always get back exactly what you\nput.\n\nDmitry\n"},{"id":"64857","messageId":"20080109152219.GD23659@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801091401101.31053@racer.site","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-09T15:22:19Z","receivedAt":"2008-01-09T15:22:19Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jan 09, 2008 at 02:03:32PM +0000, Johannes Schindelin wrote:\n>\n> On Wed, 9 Jan 2008, Gregory Jefferis wrote:\n> \n> > crlf=safe [i.e. munging CRLFs only if there are no bare LFs] sounds \n> > appealing to me as well because it looks like munging that is always \n> > reversible.\n> \n> There is a bigger problem here, though: As of now, you can add a (loose) \n> object from a big file pretty easily even on a small machine, because you \n> do not need the whole buffer, but you stream it to hash-object. IIRC \n> Junio wrote a patch to allow this with \"git-add\", using fast-import, but \n> that patch probably hasn't been applied.\n\nI don't think that crlf=safe requires that the whole file was put into\nthe buffer. It can work with stream, but it will call die() if a file\nthat was detected as text has a naked LF.\n\nDmitry\n"},{"id":"293726","messageId":"C3AAB6C3.10C6B%jefferis@gmail.com","threadId":"11505","inReplyTo":"20080109150310.GC23659@dpotapov.dyndns.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Gregory Jefferis","fromEmail":"jefferis@gmail.com","sentAt":"2008-01-09T17:37:07Z","receivedAt":"2008-01-09T17:37:07Z","isPatch":false,"sender":{"key":"jefferis@gmail.com","avatar":"https://gravatar.com/avatar/8528f4e227ebc88380c203c816e263246064e31f6180681dc2c6dabfaff24d6b?d=mp&s=160"},"body":"On 9/1/08 15:03, \"Dmitry Potapov\" wrote:\n\n> On Wed, Jan 09, 2008 at 01:52:59PM +0000, Gregory Jefferis wrote:\n>> \n>> Re point (1) to be reversible in practice, we need to know who we've munged.\n>> Otherwise when gnuming blindly at checkout we might damage some innocent\n>> bystander file that only ever had LFs in the first place.\n> \n> If you work on Windows and you have clrf=safe, you cannot put a text\n> file that has only LFs, because naked LF is not allowed. If you want\n> to have naked LF in some file, you have to say that explicitly in\n> .gitattributes.\n> \n> If you work on cross platform project, and somebody else put a file with\n> bare LFs, which is not text though heauristic wrongly detected it as\n> text then you can remove this file from your working directory, correct\n> .gitattributes and checkout this file again. The idea of crlf=safe is\n> that information is never lost. It is always fully reversible, and if\n> you put something into the repostory, you always get back exactly the\n> same unless you changed your .gitattributes.\n> \n>> Re (2) well if we happen to munge a file on checkin that is actually binary,\n>> it must be gnumed on the way out otherwise it will be broken for the user.\n> \n> Of course, it will, because the same heuristic will detect it as text,\n> and convert it back. So as long as you stay on the same platform and\n> with the same .gitattributes, you always get back exactly what you\n> put.\n\nDmitry, I think all of your comments are correct, BUT, this behaviour as\ncurrently proposed still does not seem to me safe (or perhaps transparent)\nenough to be enabled by default on a Windows platform (or for that matter a\nUnix one).\n\nIf LF text files checked in on Windows get turned into CRLF files on\ncheckout by default then I think plenty of people would be surprised and\nprobably unhappy. Similarly I think it would be a bad thing if a binary\nfile that looked like LF only text got mangled on checkout by LF->CRLF\nconversion - although I agree that it would be possible to recover from this\nsituation with a bit of juggling.\n\nSo my view is still that this behaviour would be a useful option when\nexplicitly enabled by .gitattributes (as opposed to the current auto CRLF\nimplementation, which could lead to irreversible munging) but that it is not\nan appropriate system-wide default. I could however see that sane people\nmight disagree! \n\nFor that matter autocrlf=true,input,safe are all slightly dubious when used\nas config vars rather than as attributes for the same collateral damage\nreason discussed above. The only way to prevent collateral damage is to\nconsult .gitattributes on checkout (as Dmitry seemed to be assuming above)\nrather than gnuming anything in the repository that looked like LF only\ntext. Of course even .gitattributes can change over time, so only by\nstoring a \"munged\" metadata attribute in the repository could you guarantee\nthat everything came out as it went in - which I think is a highly desirable\nbase state. \n\nGreg.\n\n"},{"id":"64862","messageId":"20080109184630.GB20892@efreet.light.src","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-01-09T18:46:30Z","receivedAt":"2008-01-09T18:46:30Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Jan 08, 2008 at 11:56:00 +0100, Peter Karlsson wrote:\n> Thomas Neumann:\n> \n> > as a user, I expect a SCM to only modify a file when I have\n> > explicitly asked it to do so.\n> \n> As a user, I exepect things to just work. With RCS/CVS/Subversion, it\n> does, because it differentiates between text files (internally encoding\n> NLs with \"LF\", but I couldn't care less what it uses there) and binary\n> files (which it doesn't change). With git it currently doesn't since it\n> treats everything as binary files.\n\nWith subversion you must explicitely enable it to \"just\" work. Subversion\nauto-tags files with specified extensions, when they are added, with\nsvn:eol property specifying how the file should be converted and than\nconverts (everywhere) the files to specified line endings. However, AFAIK, it\ndoes not convert anything unless the properties are set and the default\nconfig has the automatic setting *commented out*.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"64864","messageId":"20080109190504.GF23659@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"C3AAB6C3.10C6B%jefferis@gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-09T19:05:04Z","receivedAt":"2008-01-09T19:05:04Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"Hi Gregory,\n\nOn Wed, Jan 09, 2008 at 05:37:07PM +0000, Gregory Jefferis wrote:\n> \n> If LF text files checked in on Windows get turned into CRLF files on\n> checkout by default then I think plenty of people would be surprised and\n> probably unhappy.\n\nLF text cannot be checked in with autocrlf=safe without marking that there\nis no CRLF conversation for this file. So, what you describe is impossible.\nIOW, you *always* get back what you put in the repository.\n\n> Similarly I think it would be a bad thing if a binary\n> file that looked like LF only text got mangled on checkout by LF->CRLF\n> conversion - although I agree that it would be possible to recover from this\n> situation with a bit of juggling.\n\nAgain, you can't do that with autocrlf=safe. Yes, it is possible that\nsomeone else on Unix to put a file like this, but it is a rare event and\neasy to recover. So, it is a very small price to pay for cross-platform\nprojects, and those who use the same platform are not affected at all!\n\n> The only way to prevent collateral damage is to\n> consult .gitattributes on checkout (as Dmitry seemed to be assuming above)\n\nYes, I assumed this. Isn't it how it is implemented now?\n\nstatic int crlf_to_worktree(const char *path, const char *src, size_t len,\n struct strbuf *buf, int action)\n{\n\tchar *to_free = NULL;\n\tstruct text_stat stats;\n\n\tif ((action == CRLF_BINARY) || (action == CRLF_INPUT) ||\n\t auto_crlf <= 0)\n\t\treturn 0;\n\nIf crlf=false for some file then action will be CRLF_BINARY, and\ncrlf_to_worktree will not convert LF to CRLF. Did I miss somthing?\n\nDmitry\n"},{"id":"64868","messageId":"7vmyrehhkd.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801091041570.31053@racer.site","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-09T20:25:54Z","receivedAt":"2008-01-09T20:25:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> IMHO this is really not good. Better do it in the global /etc/gitconfig \n> we install _anyway_ (it says core.symlinks=false).\n\nThat sounds like a perfect place for a per-platform tweak like\nthis than in the code, but I wonder if peoples' scripts have\nvalid use case of GIT_CONFIG to bypass it (git-svn's use of the\nvariable to access its private data seems to be Ok).\n\n>> Perhaps we can do something similar to core.filemode? Create a file \n>> that we would need to create anyway in \"text\" mode, and read it back in \n>> \"binary\" mode to see what stdio did?\n>\n> The problem is that MinGW behaves sanely, i.e. it does not output CRLF but \n> only LF.\n\nWon't that behaviour be viewed rather as \"insanely\" from\nmajority of Windows users?\n\n> But maybe I am the minority here, and we really should default to \n> crlf=true on Windows, and provide a way to unset that.\n>\n> My preference would be to have Peff's -c switch to clone, but \n> _additionally_ a way to force a full re-checkout of files (for example \n> after \"git config core.crlf false\").\n\nI have been hoping a better (simpler to use, and somewhat more\nimportantly harder to misuse by being not overly flexible) way\nthan that \"clone -c\" solution, but that is an implementation\nissue (I think the tweak rather belongs to init than clone\nanyway, and the point of \"-c\" is that it is not easy to tweak\nthe way \"init\" that is used by \"clone\" behaves).\n\nSwitching core.crlf (or gitattributes to change filter -- in\ngeneral, \"affecting the way convert_to_working_tree() and\nconvert_to_git() works\") can be done for two opposite reasons.\n\n (1) repository is correct and checkout is wrong. This wants\n re-checkout.\n\n (2) repository records in a wrong convention by mistake and\n needs to be fixed. Re-checkout is obviously a wrong thing\n to do, and re-checkin (not necessarily commit, but updating\n the index) is necessary.\n\nWe need both.\n"},{"id":"64871","messageId":"alpine.LSU.1.00.0801092047190.31053@racer.site","threadId":"11505","inReplyTo":"7vmyrehhkd.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","sentAt":"2008-01-09T20:50:35Z","receivedAt":"2008-01-09T20:50:35Z","isPatch":false,"sender":{"key":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","avatar":null},"body":"\nHi,\n\nOn Wed, 9 Jan 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Junio wrote:\n> >\n> >> Perhaps we can do something similar to core.filemode? Create a file \n> >> that we would need to create anyway in \"text\" mode, and read it back \n> >> in \"binary\" mode to see what stdio did?\n> >\n> > The problem is that MinGW behaves sanely, i.e. it does not output CRLF \n> > but only LF.\n> \n> Won't that behaviour be viewed rather as \"insanely\" from majority of \n> Windows users?\n\nI think the truth is that CRLF was a mistake. Nobody wants to take the \nblame for it, obviously, but more and more Windows tools just grok LF-only \ntext.\n\nThe question is: what to do with those that cannot grok LF-only text. I \nimagine that the best compromise for now would be to have crlf=true, with \npoor souls like Steffen having to set the gitattributes accordingly.\n\nCiao,\nDscho\n"},{"id":"64874","messageId":"41A4384C-1D8D-4111-8C2C-90B6E8F6364C@zib.de","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801092047190.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska-wjoc1khpmeg@public.gmane.org","sentAt":"2008-01-09T21:03:35Z","receivedAt":"2008-01-09T21:03:35Z","isPatch":false,"sender":{"key":"prohaska-wjoc1khpmeg@public.gmane.org","avatar":null},"body":"\n\nOn Jan 9, 2008, at 9:50 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Wed, 9 Jan 2008, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>>\n>>> Junio wrote:\n>>>\n>>>> Perhaps we can do something similar to core.filemode? Create a \n>>>> file\n>>>> that we would need to create anyway in \"text\" mode, and read it \n>>>> back\n>>>> in \"binary\" mode to see what stdio did?\n>>>\n>>> The problem is that MinGW behaves sanely, i.e. it does not output \n>>> CRLF\n>>> but only LF.\n>>\n>> Won't that behaviour be viewed rather as \"insanely\" from majority of\n>> Windows users?\n>\n> I think the truth is that CRLF was a mistake. Nobody wants to take \n> the\n> blame for it, obviously, but more and more Windows tools just grok \n> LF-only\n> text.\n>\n> The question is: what to do with those that cannot grok LF-only \n> text. I\n> imagine that the best compromise for now would be to have \n> crlf=true, with\n> poor souls like Steffen having to set the gitattributes accordingly.\n\nI could live with that but unfortunately this alone does not\nsolve all of the real-world problems happening during cross-\nplatform development. At least the problem of code copied from\nWindows to Unix and committed there should be addressed, too.\nMaybe the default on Unix should be crlf=input? I'm wondering\nwhat Linux developer would say about this?\n\nI am against changing the default of msysgit now. First I'd like\nto wait how the \"crlf=safe\" discussion evolves.\n\n\tSteffen\n"},{"id":"64915","messageId":"Pine.LNX.4.64.0801101023380.11922@ds9.cixit.se","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801091041570.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Karlsson","fromEmail":"peter-wzhfs8o2nki+/kzbbbz5qq@public.gmane.org","sentAt":"2008-01-10T09:25:00Z","receivedAt":"2008-01-10T09:25:00Z","isPatch":false,"sender":{"key":"peter-wzhfs8o2nki+/kzbbbz5qq@public.gmane.org","avatar":null},"body":"\nJohannes Schindelin:\n\n> The problem is that MinGW behaves sanely, i.e. it does not output\n> CRLF but only LF.\n\nWell, that is broken, since the convention on Windows is to use CRLF.\n\n> - Windows is already slow. So slow that it is not even funny. Granted, \n> if you use Windows daily, git on MinGW seems snappy, but if you come \n> from Linux, it is slow as hell.\n\nTrue. And I run git a lot on a Novell disk share, which doesn't exactly\nhelp improve the speed either :-)\n\n> - Some tools ported to Windows from Unix do not like CRs.\n\nThose tools are broken, for the same reason as above.\n\n\nWindows has CRLF line endings. Just deal with it.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"64920","messageId":"alpine.LSU.1.00.0801101155140.31053@racer.site","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801101023380.11922-Hh8n7enkEC8qi7mQTfpNuw@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","sentAt":"2008-01-10T11:57:32Z","receivedAt":"2008-01-10T11:57:32Z","isPatch":false,"sender":{"key":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","avatar":null},"body":"\nHi,\n\nOn Thu, 10 Jan 2008, Peter Karlsson wrote:\n\n> Johannes Schindelin:\n> \n> > The problem is that MinGW behaves sanely, i.e. it does not output CRLF \n> > but only LF.\n> \n> Well, that is broken, since the convention on Windows is to use CRLF.\n\nI cannot help but wonder what exactly you wanted to achieve with this \nprovably bogus statement, other than provoking flames. I hereby refuse to \ninsult you for it.\n\n> > - Windows is already slow. So slow that it is not even funny. \n> > Granted, if you use Windows daily, git on MinGW seems snappy, but if \n> > you come from Linux, it is slow as hell.\n> \n> True. And I run git a lot on a Novell disk share, which doesn't exactly \n> help improve the speed either :-)\n\nDon't do that, then.\n\nI mean, git is _distributed_. Not like there is no way out because your \n\"server\" is on a disk share.\n\n> Windows has CRLF line endings. Just deal with it.\n\nNo, I will not just deal with it.\n\nCiao,\nDscho\n"},{"id":"64929","messageId":"Pine.LNX.4.64.0801101424580.11922@ds9.cixit.se","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801101155140.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Karlsson","fromEmail":"peter-wzhfs8o2nki+/kzbbbz5qq@public.gmane.org","sentAt":"2008-01-10T13:28:13Z","receivedAt":"2008-01-10T13:28:13Z","isPatch":false,"sender":{"key":"peter-wzhfs8o2nki+/kzbbbz5qq@public.gmane.org","avatar":null},"body":"\nJohannes Schindelin:\n\n> I cannot help but wonder what exactly you wanted to achieve with this\n> provably bogus statement, other than provoking flames. I hereby\n> refuse to insult you for it.\n\nI meant to say that any software that claims to be Windows software\nshould handle, and produce, CRLF line breaks in text files. Whether it\nalso supports Unix (LF) or old Mac (CR) line breaks is up to it, but if\nit is a Windows program, it should do CRLF, as that is the convention\n(inherited from MS-DOS, which inherited it from CP/M).\n\n> > True. And I run git a lot on a Novell disk share, which doesn't exactly \n> > help improve the speed either :-)\n> Don't do that, then.\n\nI have to. Otherwise the compile server can't see the files (this is\nnot for the project that at in the start of the thread, this is what I\nuse to work around that my employer's choice of version control systems\ncould be better).\n\n> > Windows has CRLF line endings. Just deal with it.\n> No, I will not just deal with it.\n\nMe neither, that is why I expect the software to do it for me.\n\nThinking of text files as a stream of bytes is so 1900s. In the 2000s\nwe should think of text files as a stream of characters. How these\ncharacters are represented is up to each system that wants it. I see no\nproblem with storing text files as UTF-32 internally (disk is cheap).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"64933","messageId":"eaa105840801100631p6b95ed86j153d70244d474b03@mail.gmail.com","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801101424580.11922@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2008-01-10T14:31:12Z","receivedAt":"2008-01-10T14:31:12Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Jan 10, 2008 8:28 AM, Peter Karlsson wrote:\n> I meant to say that any software that claims to be Windows software\n> should handle, and produce, CRLF line breaks in text files.\n\nIncluding zip/unzip? How about tar? rsync? NFS and SMB copies from\nnetwork shares? I bet the Samba folks would just *love* to have this\ndiscussion for the hundredth time.\n\nJust because CVS and FTP got the defaults wrong (and modern FTP\nclients mostly default to automatically switching to binary, so\nbasically just CVS) doesn't mean that Git has to get the default\nwrong, too. Git *does* handle and produce CRLF line breaks, as long as\nyou tell it to. Please don't lose sight of that fact.\n\nI'm just glad that VMS is effectively dead. Line endings on VMS are\nstored outside the text body, IIRC...\n\nPeter Harris\n"},{"id":"64939","messageId":"C3AC2971.10D2D%jefferis@gmail.com","threadId":"11505","inReplyTo":"7vmyrgry20.fsf@gitster.siamese.dyndns.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Gregory Jefferis","fromEmail":"jefferis@gmail.com","sentAt":"2008-01-10T19:58:41Z","receivedAt":"2008-01-10T19:58:41Z","isPatch":false,"sender":{"key":"jefferis@gmail.com","avatar":"https://gravatar.com/avatar/8528f4e227ebc88380c203c816e263246064e31f6180681dc2c6dabfaff24d6b?d=mp&s=160"},"body":"On 8/1/08 18:07, \"Junio C Hamano\" wrote:\n\n> Steffen Prohaska writes:\n> \n>> msysgit installs plain git. core.autocrlf is unset. Whatever plain\n>> git's default is, this is msysgit's default, too.\n> \n> That sounds like a mistake if you are installing a port to a\n> platform whose native line ending convention is different from\n> where plain git natively runs on (i.e. UNIX).\n\nI'm not sure that I understand the whole deal about platform default line\nendings. Isn't plain git functionally agnostic about line endings? You can\ncheck in CRLF text files to git and it doesn't care. You can diff, show etc\njust fine. I haven't yet found anything that breaks with CRLF files. In\nthis sense plain git is already Windows ready. Maybe I'm missing something?\n\nDoesn't the problem only come if you try to diff a CRLF file with a new\nversion that has LF only line endings? Then right now you have to use\nsomething like:\n\n git diff --ignore-space-at-eol\n\nOr if a Windows user clones a repository created on another system. For\nthese cross-platform circumstances, it seems to me sensible to have an\noption (probably enabled by default on all platforms) that allows files to\nbe munged on check in to whatever EOL style the repository creator preferred\n(probably stored in .gitattributes and could be different for different\nfiles in the repo - e.g. a windows vendor src dir on a cross-platform\nproject). Note that this means that munging would only happen if someone\nactually asked for it - which would be a sensible thing to do as the\nadministrator of a cross-platform project.\n\nThen there would be a separate option (probably not enabled by default) to\ncheck out with the platform's native line ending instead of whatever is in\nthe repo. This would allow people to work with inflexible toolsets.\n\nFinally for people who want to work with native line endings that are\ndifferent from repository line endings, then it might be necessary to\nimprove the handling of diffs by providing a config var to make\n--ignore-space-at-eol the default (or perhaps more correctly\n--ignore-line-endings) for text files. From my preliminary reading of list\nhistory improving the inspection of content rather than trying to change\ncontent might be the more gitish thing to do.\n\nIn conclusion all of these CRLF options are designed to help Windows users\nplay nicely with others. But it seems to me naïve Windows users can be\nperfectly happy with plain git so long as they stay in their own Windows\nworld.\n\njm2c, corrections welcome and apologies to those suffering from eol\nexhaustion,\n\nGreg.\n"},{"id":"64941","messageId":"alpine.LFD.1.00.0801101208500.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"C3AC2971.10D2D%jefferis@gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-10T20:20:15Z","receivedAt":"2008-01-10T20:20:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 10 Jan 2008, Gregory Jefferis wrote:\n> \n> I'm not sure that I understand the whole deal about platform default line\n> endings. Isn't plain git functionally agnostic about line endings? You can\n> check in CRLF text files to git and it doesn't care. You can diff, show etc\n> just fine. I haven't yet found anything that breaks with CRLF files. In\n> this sense plain git is already Windows ready. Maybe I'm missing something?\n\nIf you work together with other people on other platforms, then CRLF is a \nmajor pain in the *ss.\n\nSo you have various options:\n\n - only develop on unix-like platforms: lines end with LF, and nobody has \n any problems regardless of autocrlf behaviour. Might as well consider \n everything binary.\n\n - only develop on windows, using only one set of basic tools: lines \n normally end with CRLF, and nobody cares. Migth as well consider \n everything binary.\n\n - Mixed windows/unix platfoms, but the Windows people are constrained to \n use only tools that write text-files with LF. Might we well consider \n everything binary.\n\n Quite frankly, Johannes seems to argue that this is a viable \n alternative, but I seriously doubt that is really true. Yes, there are \n lots of Windows tools (pretty much all of them by now, I suspect) that \n *understand* LF-only line endings, but it's also undoubtedly the case \n that if you allow windows developers to use their normal tools, a \n number of them *will* write files with CRLF.\n\n - Mixed windows usage - either with other UNIX users, or even just \n *within* a windows environment if *some* of the tools are basically \n UNIX ports (ie MinGW or Cygwin without text-mounts)\n\n In this case, some tools will write files with CRLF, and others will \n write them with LF. Again, usually all tools can *read* either form, \n but the writing is mixed and depends on the tool (so if you work in a \n group where different people use different editors, you will literally \n switch back-and-forth between LF and CRLF, sometimes mixing the two in \n the same file!).\n\n This one - at the very least - basically requires \"autocrlf=input\". \n Anything else is just madness, because otherwise you'll get files that \n get partly or entirely rewritten in the object database just due to \n line ending changes.\n\nSo in *most* of the situations, you probably don't need to worry about \nautocrlf. But the thing is, I'm almost 100% convinced that the moment you \nhave even *one* windows developer, and any UNIX experience at all (whether \ndue to people actually working on unix, or just using unixy tools under \nWindows), you will end up in that final case that really does want \nautocrlf.\n\n\t\t\tLinus\n"},{"id":"64944","messageId":"47868530.2010501@dawes.za.net","threadId":"11505","inReplyTo":"C3AC2971.10D2D%jefferis@gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2008-01-10T20:50:56Z","receivedAt":"2008-01-10T20:50:56Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Gregory Jefferis wrote:\n\n> I'm not sure that I understand the whole deal about platform default line\n> endings. Isn't plain git functionally agnostic about line endings? You can\n> check in CRLF text files to git and it doesn't care. You can diff, show etc\n> just fine. I haven't yet found anything that breaks with CRLF files. In\n> this sense plain git is already Windows ready. Maybe I'm missing something?\n> \n> Doesn't the problem only come if you try to diff a CRLF file with a new\n> version that has LF only line endings? Then right now you have to use\n> something like:\n> \n> git diff --ignore-space-at-eol\n> \n\n> In conclusion all of these CRLF options are designed to help Windows users\n> play nicely with others. But it seems to me naïve Windows users can be\n> perfectly happy with plain git so long as they stay in their own Windows\n> world.\n> \n> jm2c, corrections welcome and apologies to those suffering from eol\n> exhaustion,\n> \n> Greg.\n\n\nOne example that bit me recently was \"git-apply --whitespace=strip\"\n\nI have files with CRLF in my repo, but git was stripping the CR from \nlines that I applied via a patch.\n\nI worked around it with a smudge/clean filter of \"dos2unix | unix2dos\" \n(first removes all CR's, second puts one back on each line)\n\nRogan\n"},{"id":"64952","messageId":"C3AC3B59.10D40%jefferis@gmail.com","threadId":"11505","inReplyTo":"47868530.2010501@dawes.za.net","subject":"Re: CRLF problems with Git on Win32","fromName":"Gregory Jefferis","fromEmail":"jefferis@gmail.com","sentAt":"2008-01-10T21:15:05Z","receivedAt":"2008-01-10T21:15:05Z","isPatch":false,"sender":{"key":"jefferis@gmail.com","avatar":"https://gravatar.com/avatar/8528f4e227ebc88380c203c816e263246064e31f6180681dc2c6dabfaff24d6b?d=mp&s=160"},"body":"On 10/1/08 20:50, \"Rogan Dawes\" wrote:\n\n> Gregory Jefferis wrote:\n>> Isn't plain git functionally agnostic about line endings? You can\n>> check in CRLF text files to git and it doesn't care. You can diff, show etc\n>> just fine. I haven't yet found anything that breaks with CRLF files. In\n>> this sense plain git is already Windows ready. Maybe I'm missing something?\n> \n> One example that bit me recently was \"git-apply --whitespace=strip\"\n> \n> I have files with CRLF in my repo, but git was stripping the CR from\n> lines that I applied via a patch.\n> \n> I worked around it with a smudge/clean filter of \"dos2unix | unix2dos\"\n> (first removes all CR's, second puts one back on each line)\n> \n> Rogan\n\nOK so that's interesting. Is it a case where core git is not crlf agnostic?\nLooks like CR is being considered whitespace. I think git diff\n--ignore-space-at-eol also works because CR is considered whitespace. Maybe\nthat's the wrong behaviour.\n\nSo the big question for me. Should git expect that text files inside a\nrepository have to have LF only line endings? I don't think that it should,\nbut should accommodate both CRLF and LF. I guess at the moment git normally\naccommodates CRLF files because they look like an LF file that happens to\nhave a funky whitespace char in front of the LFs. Maybe it would be better\nif edge cases like the one you described were ironed out.\n"},{"id":"64953","messageId":"C3AC3E6F.10D42%jefferis@gmail.com","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801101208500.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Gregory Jefferis","fromEmail":"jefferis@gmail.com","sentAt":"2008-01-10T21:28:15Z","receivedAt":"2008-01-10T21:28:15Z","isPatch":false,"sender":{"key":"jefferis@gmail.com","avatar":"https://gravatar.com/avatar/8528f4e227ebc88380c203c816e263246064e31f6180681dc2c6dabfaff24d6b?d=mp&s=160"},"body":"On 10/1/08 20:20, \"Linus Torvalds\" wrote:\n\n> - Mixed windows usage - either with other UNIX users, or even just\n> *within* a windows environment if *some* of the tools are basically\n> UNIX ports (ie MinGW or Cygwin without text-mounts)\n> \n> In this case, some tools will write files with CRLF, and others will\n> write them with LF. Again, usually all tools can *read* either form,\n> but the writing is mixed and depends on the tool (so if you work in a\n> group where different people use different editors, you will literally\n> switch back-and-forth between LF and CRLF, sometimes mixing the two in\n> the same file!).\n> \n> This one - at the very least - basically requires \"autocrlf=input\".\n> Anything else is just madness, because otherwise you'll get files that\n> get partly or entirely rewritten in the object database just due to\n> line ending changes.\n\nSo this is what has to be accommodated. But instead of having autocrlf\nalways set on Windows and always converting to LF in the repository, why not\ndo nothing by default unless the repository contains some information\nspecifying that it wants some or all text files to have a particular kind of\nline ending (e.g. in gitattributes). Then the choice of line ending inside\nthe repository is up to the people creating/maintaining the repo, which just\nseems right. \n\nInsisting that repos created on windows should have textfiles munged to LF\nby default doesn't seem right. Even using Dmitry's clever autocrlf=safe\noption on Windows would lead to inconvenience since all LF files have to be\nexplicitly attributed as text. We should be helping Windows people to use\nLF files rather than hindering them!\n"},{"id":"64968","messageId":"20080110232344.GD3197@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"C3AC3E6F.10D42%jefferis@gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-10T23:23:44Z","receivedAt":"2008-01-10T23:23:44Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jan 10, 2008 at 09:28:15PM +0000, Gregory Jefferis wrote:\n> \n> Insisting that repos created on windows should have textfiles munged to LF\n> by default doesn't seem right. Even using Dmitry's clever autocrlf=safe\n> option on Windows would lead to inconvenience since all LF files have to be\n> explicitly attributed as text. We should be helping Windows people to use\n> LF files rather than hindering them!\n\nI think people may have different preferences about that. Some people\nmay want to have text files with CRLF but others with LF. Some trust Git\nheuristic for detecting text files (which seems works rahter good for\nmost commonly used formats) but others are paranoid about loss some\ndata. Finally, there are some people, who just wants to store their\nmessy files as is. Based on that, the following options are possible:\n\n1. autocrlf=input for those who want LF and trust Git text heuristic\n2. autocrlf=true is for those who want CRLF and trust Git text heuristic\n3. autocrlf=fail for those who want LF but do not trust Git heuristic\n4. autocrlf=safe for those who want CRLF but do not trust Git heuristic\n5. autocrlf=false for those who like messy files with different EOLs\n\nAll these options have been mentioned in this thread, and I don't think\nwe are likely to come up with a better solution, because \"better\"\ndepends in which category of people you fall. IMHO, #5 is the least\nreasonable of all.\n\nDmitry\n"},{"id":"64970","messageId":"alpine.LFD.1.00.0801101556380.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"C3AC3E6F.10D42%jefferis@gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-11T00:02:43Z","receivedAt":"2008-01-11T00:02:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 10 Jan 2008, Gregory Jefferis wrote:\n> \n> So this is what has to be accommodated. But instead of having autocrlf\n> always set on Windows and always converting to LF in the repository, why not\n> do nothing by default [ .. ]\n\nWhy? You can screw yourself more, and much more easily (and much more \nsubtly), by leaving CRLF alone on Windows.\n\nThe thing is, 99.9% of all people will be *much* better off with \nautocrlf=true on Windows than with it defaulting to off (or even fail).\n\nIsn't *that* the whole point of having a default? Pick the thing that is \nthe right thing for almost everybody?\n\nAnd no, \"but think of the children..\" is not a valid argument. Sure, you \n*can* corrupt binary imags with CRLF conversion. But it's really quite \nhard, since the git heuristics for guessing are rather good. You really \nhave to work at it, and if you do, you're pretty damn likely to know about \nthe issue, so that 0.1% that really needs to not convert (and it's usually \none specific file type!) would probably not even turn off CRLF, but rather \nadd a .gitattributes entry for that one filetype!\n\n(Side note: if there are known filetype extensions that have problems with \nthe git guessing, we sure as heck could take the filename into account \nwhen guessing! There's absolutely nothing that says that we only have to \nlook at the contents when guessing about the text/binary thing!)\n\n\t\t\tLinus\n"},{"id":"64971","messageId":"7vir215hj0.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801101556380.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-11T00:32:03Z","receivedAt":"2008-01-11T00:32:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> (Side note: if there are known filetype extensions that have problems with \n> the git guessing, we sure as heck could take the filename into account \n> when guessing! There's absolutely nothing that says that we only have to \n> look at the contents when guessing about the text/binary thing!)\n\nYou do not have to yell.\n\nInstead, just give yourself a pat in the back for having a\nbrilliant foresight to give \"path\" parameter when you did\n6c510bee2013022fbce52f4b0ec0cc593fc0cc48 (Lazy man's auto-CRLF)\nto convert_to_git() function, even though the code originally\ndid not use it back then ;-).\n"},{"id":"64973","messageId":"7v63y15fhu.fsf@gitster.siamese.dyndns.org","threadId":"11505","inReplyTo":"47868530.2010501@dawes.za.net","subject":"Re: CRLF problems with Git on Win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-11T01:15:57Z","receivedAt":"2008-01-11T01:15:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rogan Dawes writes:\n\n> One example that bit me recently was \"git-apply --whitespace=strip\"\n\nYou might want to go back the list archive for a few days to\nfind this patch:\n\n [PATCH 2/2] core.whitespace cr-at-eol-is-ok\n\nand try it out.\n"},{"id":"65498","messageId":"buo1w8pm5bm.fsf__23043.1283395321$1200465417$gmane$org@dhapc248.dev.necel.com","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801101155140.31053@racer.site","subject":"Re: CRLF problems with Git on Win32","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-01-11T03:03:41Z","receivedAt":"2008-01-11T03:03:41Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"\n\n\nJohannes Schindelin \nwrites:\n>> Windows has CRLF line endings. Just deal with it.\n>\n> No, I will not just deal with it.\n\nDidn't Apple change their line-ending convention, moving to LF EOL with OSX?\n\n-Miles\n\n-- \n\"I distrust a research person who is always obviously busy on a task.\"\n --Robert Frosch, VP, GM Research\n"},{"id":"299222","messageId":"buo1w8pm5bm.fsf@dhapc248.dev.necel.com","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801101155140.31053@racer.site","subject":"Re: CRLF problems with Git on Win32","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-01-11T03:03:41Z","receivedAt":"2008-01-11T03:03:41Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"\n\n\nJohannes Schindelin \nwrites:\n>> Windows has CRLF line endings. Just deal with it.\n>\n> No, I will not just deal with it.\n\nDidn't Apple change their line-ending convention, moving to LF EOL with OSX?\n\n-Miles\n\n-- \n\"I distrust a research person who is always obviously busy on a task.\"\n --Robert Frosch, VP, GM Research\n\n\n"},{"id":"64986","messageId":"7EAB1DA8-627D-455E-AA23-C404FDC615D9@zib.de","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801101556380.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-11T07:10:25Z","receivedAt":"2008-01-11T07:10:25Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 11, 2008, at 1:02 AM, Linus Torvalds wrote:\n\n>\n>\n> On Thu, 10 Jan 2008, Gregory Jefferis wrote:\n>>\n>> So this is what has to be accommodated. But instead of having \n>> autocrlf\n>> always set on Windows and always converting to LF in the \n>> repository, why not\n>> do nothing by default [ .. ]\n>\n> Why? You can screw yourself more, and much more easily (and much more\n> subtly), by leaving CRLF alone on Windows.\n>\n> The thing is, 99.9% of all people will be *much* better off with\n> autocrlf=true on Windows than with it defaulting to off (or even \n> fail).\n>\n> Isn't *that* the whole point of having a default? Pick the thing \n> that is\n> the right thing for almost everybody?\n\nAre you also for \"autocrlf=input\" as the default on Unix? This\nis the second half of the solution to the cross-platform problem ...\n\n\n> And no, \"but think of the children..\" is not a valid argument. \n> Sure, you\n> *can* corrupt binary imags with CRLF conversion. But it's really quite\n> hard, since the git heuristics for guessing are rather good. You \n> really\n> have to work at it, and if you do, you're pretty damn likely to \n> know about\n> the issue, so that 0.1% that really needs to not convert (and it's \n> usually\n> one specific file type!) would probably not even turn off CRLF, but \n> rather\n> add a .gitattributes entry for that one filetype!\n\n... and then Windows and Unix users would have the same chance of\ndata corruption.\n\nWhich is very low, yes, but unfortunately it already hit me once\nand I didn't immediately recognized what happend. I guess that\nless experienced git used would have a harder time to understand.\nHowever, I don't have a test case at hand. I should probably\nbetter go and find one. So for now, you may just want to ignore\nthis comment.\n\nYet, I'm a bit paranoid about the potential data corruption. The\nway data would be corrupted during commit can't be easily fixed.\nYou only have a chance for fixing this if you recognize the\nproblem before you delete the file in your work tree. But\nbecause git is extremely good at preserving your data once you\ncommitted a file, I tend to feel _very_ safe after I committed and\nI am teaching all people that once they committed data to git\nthey'll not loose it until the reflog expires (well and obviously\nthey must not delete .git).\n\n\n> (Side note: if there are known filetype extensions that have \n> problems with\n> the git guessing, we sure as heck could take the filename into account\n> when guessing! There's absolutely nothing that says that we only \n> have to\n> look at the contents when guessing about the text/binary thing!)\n\nLooking on the content seems the right thing to do. The filetype\nextension could be misleading.\n\nMaybe a mechanism similar to the file command would be more\nvaluable. I guess a stripped down variant should be sufficient.\n\n\tSteffen\n"},{"id":"65016","messageId":"Pine.LNX.4.64.0801111409400.2497@ds9.cixit.se","threadId":"11505","inReplyTo":"eaa105840801100631p6b95ed86j153d70244d474b03-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Karlsson","fromEmail":"peter-wzhfs8o2nki+/kzbbbz5qq@public.gmane.org","sentAt":"2008-01-11T13:12:19Z","receivedAt":"2008-01-11T13:12:19Z","isPatch":false,"sender":{"key":"peter-wzhfs8o2nki+/kzbbbz5qq@public.gmane.org","avatar":null},"body":"\nPeter Harris:\n\n> > I meant to say that any software that claims to be Windows software\n> > should handle, and produce, CRLF line breaks in text files.\n\n> Including zip/unzip?\n\nYup (zip -l, unzip -a).\n\n> How about tar? rsync? \n\nSure.\n\n> NFS and SMB copies from network shares?\n\nI'd say that might not be as obvious, but it would be nice to have,\nyes. A typed network file system that stores text as character streams\nand binary data as octet streams.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"65027","messageId":"eaa105840801110739w5b47c671n790f0dbdc9b0d2fd@mail.gmail.com","threadId":"11505","inReplyTo":"Pine.LNX.4.64.0801111409400.2497@ds9.cixit.se","subject":"Re: CRLF problems with Git on Win32","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2008-01-11T15:39:33Z","receivedAt":"2008-01-11T15:39:33Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Jan 11, 2008 8:12 AM, Peter Karlsson wrote:\n> > > I meant to say that any software that claims to be Windows software\n> > > should handle, and produce, CRLF line breaks in text files.\n>\n> > Including zip/unzip?\n>\n> Yup (zip -l, unzip -a).\n\nHow is this any different from core.autocrlf? You get CRLF conversion\nif you ask for it, and not if you don't.\n\nPeter Harris\n"},{"id":"65029","messageId":"alpine.LFD.1.00.0801110756260.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"7EAB1DA8-627D-455E-AA23-C404FDC615D9@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-11T15:58:41Z","receivedAt":"2008-01-11T15:58:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 11 Jan 2008, Steffen Prohaska wrote:\n> \n> Are you also for \"autocrlf=input\" as the default on Unix?\n\nNo. What would it help?\n\n\"autocrlf\" on Windows actually helps you (big upside, very small \ndownside). On Unix or other sane systems, it has zero upside, so while the \nrisk is still very small, there is now no big upside to counteract it.\n\nAgain, what is \"default\" supposed to be? I argue that it's supposed to be \nthe thing that is right for 99.9% of all people. And that simply isn't \ntrue on Unix.\n\n\t\tLinus\n"},{"id":"65032","messageId":"D36EB89D-11A3-4EAF-BC1C-6100383FCBFC@zib.de","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801110756260.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-11T16:28:47Z","receivedAt":"2008-01-11T16:28:47Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 11, 2008, at 4:58 PM, Linus Torvalds wrote:\n\n>\n>\n> On Fri, 11 Jan 2008, Steffen Prohaska wrote:\n>>\n>> Are you also for \"autocrlf=input\" as the default on Unix?\n>\n> No. What would it help?\n\nYou may later decide that you want to check out your project on Windows.\nIn this case your repository should not contain CRLF. autocrlf=input\nensures this.\n\nSo given the current options, autocrlf=input is the only\nreasonable default on Unix if git wants to support cross-platform\ndevelopment as its default.\n\n\n> \"autocrlf\" on Windows actually helps you (big upside, very small\n> downside). On Unix or other sane systems, it has zero upside, so \n> while the\n> risk is still very small, there is now no big upside to counteract it.\n\nautocrlf=input on Unix helps cross-platform development, too.\n\n\n> Again, what is \"default\" supposed to be? I argue that it's supposed \n> to be\n> the thing that is right for 99.9% of all people. And that simply isn't\n> true on Unix.\n\nautocrlf=input is true for the very same people that need autocrlf=true\non Windows. Every developer who ever plans to check out his code on\nWindows and on Unix should have these default.\n\nI don't think the CRLF problem is a Windows vs. Unix discussion.\nIn my view, the discussion is wether git will have real cross-\nplatform support as its default or not. The current default is\nsane for native Unix or native Windows projects. For cross-\nplatform projects the default needs to be changed in the way\ndescribed above. Git needs to ensure that CRLF never enters the\nrepository for text files. If you did not set autocrlf=true,\ncopying source code from Windows to Unix would not be supported.\nBut as you earlier mentioned, this seems to be a common\noperation and I am observing the same. So I recommend\nautocrlf=input on Unix if you plan to ever go cross-platform.\n\n\tSteffen\n"},{"id":"65037","messageId":"alpine.LFD.1.00.0801110924380.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"D36EB89D-11A3-4EAF-BC1C-6100383FCBFC@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-11T17:25:52Z","receivedAt":"2008-01-11T17:25:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 11 Jan 2008, Steffen Prohaska wrote:\n> > \n> > No. What would it help?\n> \n> You may later decide that you want to check out your project on Windows.\n> In this case your repository should not contain CRLF. autocrlf=input\n> ensures this.\n\nBut under Unix, it would never do that *anyway*, unless the file for some \nreason really needs it (which I cannot imagine, but I've never seen \nanything so craptastically stupid that some crazy person hasn't done it)\n\nSo your argument is bogus.\n\n\t\tLinus\n"},{"id":"65039","messageId":"930EC77A-73D1-4DDD-81D4-BF22B248FCB6@zib.de","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801110924380.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-11T17:56:49Z","receivedAt":"2008-01-11T17:56:49Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 11, 2008, at 6:25 PM, Linus Torvalds wrote:\n\n>\n>\n> On Fri, 11 Jan 2008, Steffen Prohaska wrote:\n>>>\n>>> No. What would it help?\n>>\n>> You may later decide that you want to check out your project on \n>> Windows.\n>> In this case your repository should not contain CRLF. autocrlf=input\n>> ensures this.\n>\n> But under Unix, it would never do that *anyway*, unless the file \n> for some\n> reason really needs it (which I cannot imagine, but I've never seen\n> anything so craptastically stupid that some crazy person hasn't \n> done it)\n>\n> So your argument is bogus.\n\nAh sorry, I misunderstood you in [1]. I thought your last point\n\"Mixed Windows usage\" meant what I have in mind: A user working\nin a mixed Windows/Unix environment who creates a file using\nWindows tools and commits it in the Unix environment. In this\ncase the CRLF file will be transferred from Windows to Unix\nwithout git being involved. The right thing for git on Unix is\nto remove CRLF during a commit but still write only LF during\ncheck out. So autocrlf=input is the right choice.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/70082\n\nIt happens that people working in a mixed environment do such things.\nThey just copy files from Windows to Unix and commit there. Not very\noften, but it happens. So it would be nice if git would handle this\nsituation and it actually can by setting autocrlf=input.\n\nMy point is that perfect support for mixed environments requires\nthat git removes CRLF from any input on any platform. However,\ngit should behave differently during checkout. In this case the\nnative line ending should be written (LF on Unix, CRLF on\nWindows). The difference happens during check out; commit should\nbe handled identically.\n\n\tSteffen\n"},{"id":"65040","messageId":"alpine.LFD.1.00.0801111005360.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"930EC77A-73D1-4DDD-81D4-BF22B248FCB6@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-11T18:10:00Z","receivedAt":"2008-01-11T18:10:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 11 Jan 2008, Steffen Prohaska wrote:\n> \n> Ah sorry, I misunderstood you in [1]. I thought your last point\n> \"Mixed Windows usage\" meant what I have in mind: A user working\n> in a mixed Windows/Unix environment who creates a file using\n> Windows tools and commits it in the Unix environment. In this\n> case the CRLF file will be transferred from Windows to Unix\n> without git being involved. The right thing for git on Unix is\n> to remove CRLF during a commit but still write only LF during\n> check out. So autocrlf=input is the right choice.\n\nOh, ok, I didn't realize.\n\nBut yes, if you use a network share across windows and Unixand actually \n*share* the working tree over it, then yes, you'd want \"autocrlf=input\" on \nthe unix side.\n\nHowever, I think that falls under the \"0.1%\" case, not the \"99.9%\" case.\n\nI realize that people probably do that more often with centralized \nsystems, but with a distributed thing, it probably makes a *ton* more \nsense to have separate trees. But I could kind of see having a shared \ndevelopment directory and accessing it from different types of machines \ntoo.\n\nI'd also bet that crlf behavior of git itself will be the *least* of your \nproblems in that situation. You'd have all the *other* tools to worry \nabout, and would probably be very aware indeed of any CRLF issues. So at \nthat point, the \"automatic\" or default behaviour is probably not a big \ndeal, because everything _else_ you do likely needs special effort too!\n\n\t\t\tLinus\n"},{"id":"65043","messageId":"14E7B5D5-B1B8-4532-A471-106B14B912B8@zib.de","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801111005360.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-11T18:29:07Z","receivedAt":"2008-01-11T18:29:07Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jan 11, 2008, at 7:10 PM, Linus Torvalds wrote:\n\n>\n>\n> On Fri, 11 Jan 2008, Steffen Prohaska wrote:\n>>\n>> Ah sorry, I misunderstood you in [1]. I thought your last point\n>> \"Mixed Windows usage\" meant what I have in mind: A user working\n>> in a mixed Windows/Unix environment who creates a file using\n>> Windows tools and commits it in the Unix environment. In this\n>> case the CRLF file will be transferred from Windows to Unix\n>> without git being involved. The right thing for git on Unix is\n>> to remove CRLF during a commit but still write only LF during\n>> check out. So autocrlf=input is the right choice.\n>\n> Oh, ok, I didn't realize.\n>\n> But yes, if you use a network share across windows and Unixand \n> actually\n> *share* the working tree over it, then yes, you'd want \n> \"autocrlf=input\" on\n> the unix side.\n>\n> However, I think that falls under the \"0.1%\" case, not the \"99.9%\" \n> case.\n>\n> I realize that people probably do that more often with centralized\n> systems, but with a distributed thing, it probably makes a *ton* more\n> sense to have separate trees. But I could kind of see having a shared\n> development directory and accessing it from different types of \n> machines\n> too.\n\nIt just happens yesterday that I copied a file from Unix to Windows\n(lucky I am ;) for a quite simple reason. I fetched and merged and\nrealized that another developer forgot to check in a new file. He\nhad already left. So I just looked into his workspace and copied\nthe file. This has nothing to do with centralized system or not.\nWe're just working in a mixed OS environment with shared filesystems.\n\nI didn't even think about the line endings in this situation because\neverything just worked. Actually I like the idea that I do not\nneed to think about the endings because git will care about them.\nActually many other tools work well with CRLF. For example, vi\njust displays [dos] in its status bar; but besides this everything\nis just fine.\n\n\n> I'd also bet that crlf behavior of git itself will be the *least* \n> of your\n> problems in that situation. You'd have all the *other* tools to worry\n> about, and would probably be very aware indeed of any CRLF issues. \n> So at\n> that point, the \"automatic\" or default behaviour is probably not a big\n> deal, because everything _else_ you do likely needs special effort \n> too!\n\nI don't think so. In the setting I described above, the questions I \nreceive\nare not about the other tools but about git. I already started to teach\neveryone the new \"autocrlf=input\" policy to avoid these questions. I \ndon't\ncare that much about potential file corruption (though I'd feel more\ncomfortable if I knew git would have stronger guarantees). During \nthe next\ncheckout on Windows file corruption would happen anyway.\n\n\tSteffen\n"},{"id":"65050","messageId":"C3AD6D58.10E02%jefferis@gmail.com","threadId":"11505","inReplyTo":"D36EB89D-11A3-4EAF-BC1C-6100383FCBFC@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Gregory Jefferis","fromEmail":"jefferis@gmail.com","sentAt":"2008-01-11T19:00:40Z","receivedAt":"2008-01-11T19:00:40Z","isPatch":false,"sender":{"key":"jefferis@gmail.com","avatar":"https://gravatar.com/avatar/8528f4e227ebc88380c203c816e263246064e31f6180681dc2c6dabfaff24d6b?d=mp&s=160"},"body":"Sticking my head above the parapet again ...\n\nOn 11/1/08 16:28, \"Steffen Prohaska\" wrote:\n\n> I don't think the CRLF problem is a Windows vs. Unix discussion.\nAgreed.\n> In my view, the discussion is wether git will have real cross-\n> platform support as its default or not. The current default is\n> sane for native Unix or native Windows projects. For cross-\nAbsolutely\n> platform projects the default needs to be changed in the way\n> described above. Git needs to ensure that CRLF never enters the\n> repository for text files.\n\nLF only repositories are model that everyone is tending towards but I feel\nthat there are (sane) people out there who would sometimes like to have CRLF\nfiles in the repository and do cross-platform development (I would\ndeveloping on a Mac for a Windows originated Win/Mac project or if I were\nkeeping vendor source code in a tree). In spite of the plethora of autocrlf\nvariants so far there is still none that on unix would give you LF->CRLF on\ncheck in and CRLF->LF on checkout! This should be perfectly compatible with\ngit's internals and I think it should be possible to allow this without\nbreaking anything for other situations. One solution, which would have\nother uses, would be to allow checkin conversion to a specified line ending\nand checkout conversion to platform line ending as separately configurable\noptions.\n\nIf this seems outrageous then it should be made perfectly clear that the git\nproject strongly discourages CRLF text files in cross-platform repositories,\nthat to prevent CRLF creep we disallow them by default even in the privacy\nof your own OS (if it's Windows) and that if you want to do this you're on\nyour own mate. But I think that would be a shame, inflexible and definitely\nnot PC ;-)\n\n> If you did not set autocrlf=true,\n> copying source code from Windows to Unix would not be supported.\n> But as you earlier mentioned, this seems to be a common\n> operation and I am observing the same. So I recommend\n> autocrlf=input on Unix if you plan to ever go cross-platform.\n\nFor me this is kind of the mathematician vs the engineer. I think Steffen\nis logically correct in saying that autocrlf=input on unix is the direct\northologue of autocrlf=true on windows and I dislike the idea that git\nshould show logically different behaviour on different platforms. However I\nthink Linus's cost/benefit analysis is right: CRLF files appear infrequently\non unix system and often as not it's because someone specifically wants them\nto stay that way.\n\nSo I think autocrlf=input is a useful option but not a necessary default on\nunix. \n"},{"id":"65052","messageId":"alpine.LFD.1.00.0801111103420.3148@woody.linux-foundation.org","threadId":"11505","inReplyTo":"14E7B5D5-B1B8-4532-A471-106B14B912B8@zib.de","subject":"Re: CRLF problems with Git on Win32","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-11T19:16:02Z","receivedAt":"2008-01-11T19:16:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 11 Jan 2008, Steffen Prohaska wrote:\n> \n> I already started to teach everyone the new \"autocrlf=input\" policy to \n> avoid these questions.\n\nI certainly don't think \"autocrlf=input\" is wrong. It might even be a \nreasonable default on Unix, although I don't think it's nearly as obvious \nas the Windows case. I wouldn't mind using it myself, for example, \nalthough probably only because I know that for the stuff I work on it \nsimply cannot possibly ever do the wrong thing.\n\nIn fact, we had a case of bogus CRLF in one of the kernel documentation \nfiles for some reason that we ended up fixing by hand. \"autocflf=input\" \nwould have fixed it (except in that case it wouldn't have, since it came \nfrom the original kernel tree, long before crlf was an issue for git ;)\n\nSo I'd say that autocrlf=input is quite possibly a good idea on Unix in \ngeneral, but my gut feel is still that it's not a big enough issue to be \nactually worth making a default change over. But there's absolutely \nnothing wrong with having it as a policy at a company that has mixed Unix \nand Windows machines.\n\n(Every place I've ever been at, people who had a choice would never ever \ndevelop under Windows, so I've never seen any real mixing - even when some \nparts of the project were DOS/Windows stuff, there was a clear boundary \nbetween the stuff that was actually done under Windows)\n\n\t\t\tLinus\n"},{"id":"65053","messageId":"20080111195022.GC29189@uranus.ravnborg.org","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801111103420.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2008-01-11T19:50:22Z","receivedAt":"2008-01-11T19:50:22Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Fri, Jan 11, 2008 at 11:16:02AM -0800, Linus Torvalds wrote:\n> \n> \n> On Fri, 11 Jan 2008, Steffen Prohaska wrote:\n> > \n> > I already started to teach everyone the new \"autocrlf=input\" policy to \n> > avoid these questions.\n> \n> I certainly don't think \"autocrlf=input\" is wrong. It might even be a \n> reasonable default on Unix, although I don't think it's nearly as obvious \n> as the Windows case. I wouldn't mind using it myself, for example, \n> although probably only because I know that for the stuff I work on it \n> simply cannot possibly ever do the wrong thing.\n> \n> In fact, we had a case of bogus CRLF in one of the kernel documentation \n> files for some reason that we ended up fixing by hand. \"autocflf=input\" \n> would have fixed it (except in that case it wouldn't have, since it came \n> from the original kernel tree, long before crlf was an issue for git ;)\n> \n> So I'd say that autocrlf=input is quite possibly a good idea on Unix in \n> general, but my gut feel is still that it's not a big enough issue to be \n> actually worth making a default change over. But there's absolutely \n> nothing wrong with having it as a policy at a company that has mixed Unix \n> and Windows machines.\n> \n> (Every place I've ever been at, people who had a choice would never ever \n> develop under Windows, so I've never seen any real mixing - even when some \n> parts of the project were DOS/Windows stuff, there was a clear boundary \n> between the stuff that was actually done under Windows)\n\nThe reality I see is the other way around as common practice.\nFor people that has never tried a Linux box the barrier\nis quite high and they prefer to stick with Windows.\nWhere I work today and in several other places I know of the\ndefault choice is to work on Windows and use a Linux box only\nfor cross compilation.\nThis is common practice in many smaller embedded companies\nand it is also these companies that like to be able to build\nLinux on a Windows box.\n\n\tSam\n"},{"id":"65054","messageId":"20080111205349.00ebccd9@weinigel.se","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801111005360.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Christer Weinigel","fromEmail":"christer@weinigel.se","sentAt":"2008-01-11T19:53:49Z","receivedAt":"2008-01-11T19:53:49Z","isPatch":false,"sender":{"key":"christer@weinigel.se","avatar":null},"body":"On Fri, 11 Jan 2008 10:10:00 -0800 (PST)\nLinus Torvalds wrote:\n\n> On Fri, 11 Jan 2008, Steffen Prohaska wrote:\n> > Ah sorry, I misunderstood you in [1]. I thought your last point\n> > \"Mixed Windows usage\" meant what I have in mind: A user working\n> > in a mixed Windows/Unix environment who creates a file using\n> > Windows tools and commits it in the Unix environment. In this\n> > case the CRLF file will be transferred from Windows to Unix\n> > without git being involved. The right thing for git on Unix is\n> > to remove CRLF during a commit but still write only LF during\n> > check out. So autocrlf=input is the right choice.\n> \n> Oh, ok, I didn't realize.\n> \n> But yes, if you use a network share across windows and Unixand\n> actually *share* the working tree over it, then yes, you'd want\n> \"autocrlf=input\" on the unix side.\n> \n> However, I think that falls under the \"0.1%\" case, not the \"99.9%\"\n> case.\n\nThat's how I work all the time. My Linux box is a Samba server where I\ncheck things out from perforce (with the \"share\" settings for end of\nline which means that text files are checked out with LF only and CRLF\nis converted to LF on checkin). Having the data on the Linux box is\nnice since I can have all the nice Unix tools such as sed, find, grep,\nand they run fast on a native Linux system, which is not true about\ncygwin on Windows. \n\n> I realize that people probably do that more often with centralized \n> systems, but with a distributed thing, it probably makes a *ton* more \n> sense to have separate trees. But I could kind of see having a shared \n> development directory and accessing it from different types of\n> machines too.\n\nWe're working in a mixed environment, and even though I do most of my\ndevelopment on Linux I usually want to make sure that things build in\nVisual Studio before I check in, so the easiest thing to do is to point\nVisual Studio at the files on the Samba share. Same thing when using\nAltera's tools to do CPLD development, I run the Altera tools on\nWindows (their free version is Windows only) but all the files are on\nthe Linux box. My tools that take the SVF file (the \"binary image\" for\nthe CPLD) and program the CPLD all run under Linux though.\n\nA lot of my colleagues have Windows on the desktop, and when they\ndevelop on Linux they usually edit the files locally using the Samba\nshare, and then they have a Putty (ssh) connected to the Linux box\nwhere they build and test the software.\n\nSo the shared scenario is actually a very common one for us.\n\n> I'd also bet that crlf behavior of git itself will be the *least* of\n> your problems in that situation. You'd have all the *other* tools to\n> worry about, and would probably be very aware indeed of any CRLF\n> issues. So at that point, the \"automatic\" or default behaviour is\n> probably not a big deal, because everything _else_ you do likely\n> needs special effort too!\n\nActually I seldom have any problems with CRLF at all. Sometimes\nthe Xilinx or Altera editors will insert some stray CRLFs in some files,\nbut all the tools I use seem to tolerate that. And as soon as I check\nin the CRLFs disappear anyway. We just have to make sure to turn on\nthe \"share\" setting in our Perforce views and everything just works.\n\n /Christer\n"},{"id":"65063","messageId":"alpine.LSU.1.00.0801112116180.31053@racer.site","threadId":"11505","inReplyTo":"20080111195022.GC29189@uranus.ravnborg.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-11T21:18:49Z","receivedAt":"2008-01-11T21:18:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Jan 2008, Sam Ravnborg wrote:\n\n> On Fri, Jan 11, 2008 at 11:16:02AM -0800, Linus Torvalds wrote:\n> \n> > (Every place I've ever been at, people who had a choice would never \n> > ever develop under Windows, so I've never seen any real mixing - even \n> > when some parts of the project were DOS/Windows stuff, there was a \n> > clear boundary between the stuff that was actually done under Windows)\n> \n> The reality I see is the other way around as common practice.\n\nNot in my world.\n\nI see a few people who are stuck to Windows, but they are so because they \nare lazy. They do not ever do something interesting with computers in \ntheir free time, and while working, they only do what they are told to do.\n\nThat might sound cynical, but you will have to _show_ me different \nexamples to make me reconsider.\n\nAnd no, my work with msysgit did a poor job to convince me otherwise.\n\nCiao,\nDscho\n"},{"id":"65076","messageId":"20080111222126.GA30184@uranus.ravnborg.org","threadId":"11505","inReplyTo":"alpine.LSU.1.00.0801112116180.31053@racer.site","subject":"Re: CRLF problems with Git on Win32","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2008-01-11T22:21:26Z","receivedAt":"2008-01-11T22:21:26Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Fri, Jan 11, 2008 at 09:18:49PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Fri, 11 Jan 2008, Sam Ravnborg wrote:\n> \n> > On Fri, Jan 11, 2008 at 11:16:02AM -0800, Linus Torvalds wrote:\n> > \n> > > (Every place I've ever been at, people who had a choice would never \n> > > ever develop under Windows, so I've never seen any real mixing - even \n> > > when some parts of the project were DOS/Windows stuff, there was a \n> > > clear boundary between the stuff that was actually done under Windows)\n> > \n> > The reality I see is the other way around as common practice.\n> \n> Not in my world.\n> \n> I see a few people who are stuck to Windows, but they are so because they \n> are lazy. They do not ever do something interesting with computers in \n> their free time, and while working, they only do what they are told to do.\n\nSome of the people I have in my mind I will certainly not call lazy, but the\nother part of the description is a fine match.\n\n> That might sound cynical, but you will have to _show_ me different \n> examples to make me reconsider.\n\nI just wanted to say that things looks different in some places of the\nworld nad for some types of development.\nI do not even know what I should try to make you reconsider - as I did not\nfollow the full thread. Just stumbled over this statement.\n\n\tSam\n"},{"id":"65181","messageId":"20080112150842.GG2963@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"20080111195022.GC29189@uranus.ravnborg.org","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-12T15:08:42Z","receivedAt":"2008-01-12T15:08:42Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Jan 11, 2008 at 08:50:22PM +0100, Sam Ravnborg wrote:\n> On Fri, Jan 11, 2008 at 11:16:02AM -0800, Linus Torvalds wrote:\n> > \n> > (Every place I've ever been at, people who had a choice would never ever \n> > develop under Windows, so I've never seen any real mixing - even when some \n> > parts of the project were DOS/Windows stuff, there was a clear boundary \n> > between the stuff that was actually done under Windows)\n> \n> The reality I see is the other way around as common practice.\n> For people that has never tried a Linux box the barrier\n> is quite high and they prefer to stick with Windows.\n\nAnd for those who have never tried Windows, it would be a great learning\nbarrier as well, and it is far for obvious what would be easy to learn\nfor someone has never had any experience with either of them before...\nOf course, most people who has used computers for some time could not\nescape having at least some experience with Windows, and, naturally\npeople prefer to stick to what they know, especially those who do not\nlike or find difficult to learn new stuff. Based on my observation, I\nwould say that those found learning Linux difficult would also find\ndifficult to learn other new things (like a new programming language),\nand usually had more troubles in dealing with novel situations or doing\nanything that required out-of-the-box thinking... Usually, they are\ngood only on one thing -- doing what they were told. There are some\nexceptions, of course, but take a look at the number of open source\nprojects (where people write for fun of programming) and compare how\nmany of them are done by *nix users and Windows users. Isn't obvious\nwhat most people who like programing prefer to use?\n\nDmitry\n"},{"id":"65182","messageId":"20080112152615.GH2963@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"C3AD6D58.10E02%jefferis@gmail.com","subject":"Re: CRLF problems with Git on Win32","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-12T15:26:15Z","receivedAt":"2008-01-12T15:26:15Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Jan 11, 2008 at 07:00:40PM +0000, Gregory Jefferis wrote:\n> \n> LF only repositories are model that everyone is tending towards but I feel\n> that there are (sane) people out there who would sometimes like to have CRLF\n> files in the repository and do cross-platform development (I would\n> developing on a Mac for a Windows originated Win/Mac project or if I were\n> keeping vendor source code in a tree). In spite of the plethora of autocrlf\n> variants so far there is still none that on unix would give you LF->CRLF on\n> check in and CRLF->LF on checkout! This should be perfectly compatible with\n> git's internals\n\nGit internally considers only LF as the EOL marker. I think there are\nmore three hundreds places in Git where the decision about end-of-line\nis made based on that. Though CRLF may appear to work, but it is more\nan artifact caused by its LF ending, so what it actually works is LF and\nnothing else. IOW, CRLF from the Git's point of view is no better EOL\nthan let's say SPACE+LF.\n\n> and I think it should be possible to allow this without\n> breaking anything for other situations. One solution, which would have\n> other uses, would be to allow checkin conversion to a specified line ending\n> and checkout conversion to platform line ending as separately configurable\n> options.\n> \n> If this seems outrageous then it should be made perfectly clear that the git\n> project strongly discourages CRLF text files in cross-platform repositories,\n\nBecause LF is the only true EOL marker, and CRLF is not and never will be.\nIn fact, Git is written in C, and the decision of what is EOL in C is made\nmany years ago. So, it is the only sane choice to use LF for _internal_\nrepresentation. It can be said that *nix users are lucky in that their\nOS uses the same symbol, but it is similar to big-endian platforms being\nlucky with byte order when it comes to TCP/IP. That is not because TCP/IP\nwants to discourage little-endian platforms, but having the single encoding\nis the only sane choice if you care about interoperability, and any other\ndecision will end up being much worse.\n\n\nDmitry\n"},{"id":"65197","messageId":"12001604531066-git-send-email-prohaska@zib.de","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801111103420.3148@woody.linux-foundation.org","subject":"[PATCH] [WIP] safecrlf: Add mechanism to warn about irreversible crlf conversions","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-12T17:54:13Z","receivedAt":"2008-01-12T17:54:13Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"I promised to think about the CRLF discussion and here is what\nI believe we could do:\n - Leave the current core.autocrlf mechanism as is.\n - Add a mechanism to warn the user if an irreversible conversion happens\n - After we have the mechanisms for configuring the conversion and for\n configuring the safety level, we can decide which defaults to use on\n the different platforms, namely Windows and Unix.\n\nI propose to set the following defaults:\n - Unix: core.autocrlf=input, core.safecrlf=warn\n - Windows: core.autocrlf=true, core.safecrlf=warn\n\nThis patch is declared as WIP because tests and a documentation are missing.\nI'm also not sure if calling warning() and die() is the right thing to do at\nthis place. Interestingly, in some (all?) cases, crlf_to_git() is called two\ntimes for a path during git add, resulting in the warning printed two times. I\ndidn't yet analyze why this happens. Maybe the the warnings and errors printed\nshould be more verbose?\n\n[ Linus, Dimitry was right about stats.lf. ]\n\n Steffen\n\n---- snip snap ---\n\nCRLF conversion bears a slight chance of corrupting data.\nautocrlf=true will convert CRLF to LF during commit and LF to\nCRLF during checkout. A file that containes a mixture of LF and\nCRLF before the commit cannot be recreated by git. For text\nfiles this does not really matter because we do not care about\nthe line endings anyway; but for binary files that are\naccidentally classified as text the conversion can result in\ncorrupted data.\n\nIf you recognize such corruption during commit you can easily fix\nit by setting the conversion type explicitly in .gitattributes.\nRight after committing you still have the original file in your\nwork tree and this file is not yet corrupted.\n\nHowever, in mixed Windows/Unix environments text files quite\neasily can end up containing a mixture of CRLF and LF line\nendings and git should handle such situations gracefully. For\nexample a user could copy a CRLF file from Windows to Unix and\nmix it with an existing LF file there. The result would contain\nboth types of line endings.\n\nUnfortunately, the desired effect of cleaning up text files\nwith mixed lineendings and undesired effect of corrupting binary\nfiles can not be distinguished. In both cases CRLF are removed\nin an irreversible way. For text files this is the right thing\nto do, while for binary file its corrupting data.\n\nIn a sane environment committing and checking out the same file\nshould not modify the origin file in the work tree. For\nautocrlf=input the original file must not contain CRLF. For\nautocrlf=true the original file must not contain LF without\npreceding CR. Otherwise the conversion is irreversible. Note,\ngit might be able to recreate the original file with different\nautocrlf settings, but in the current environment checking out\nwill yield a file that differs from the file before the commit.\n\nThis patch adds a mechanism that can either warn the user about\nan irreversible conversion or can even refuse to convert. The\nmechanism is controlled by the variable core.safecrlf, with the\nfollowing values\n - false: disable safecrlf mechanism\n - warn: warn about irreversible conversions\n - true: refuse irreversible conversions\n\nThe default is to warn.\n\nA concept of a safety check was originally proposed in a similar\nway by Linus Torvalds.\n\nSigned-off-by: Steffen Prohaska \n---\n cache.h | 8 ++++++++\n config.c | 9 +++++++++\n convert.c | 21 +++++++++++++++++++++\n environment.c | 1 +\n 4 files changed, 39 insertions(+), 0 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 39331c2..4e03e3d 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -330,6 +330,14 @@ extern size_t packed_git_limit;\n extern size_t delta_base_cache_limit;\n extern int auto_crlf;\n \n+enum safe_crlf {\n+\tSAFE_CRLF_FALSE = 0,\n+\tSAFE_CRLF_FAIL = 1,\n+\tSAFE_CRLF_WARN = 2,\n+};\n+\n+extern enum safe_crlf safe_crlf;\n+\n #define GIT_REPO_VERSION 0\n extern int repository_format_version;\n extern int check_repository_format(void);\ndiff --git a/config.c b/config.c\nindex 857deb6..0a46046 100644\n--- a/config.c\n+++ b/config.c\n@@ -407,6 +407,15 @@ int git_default_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.safecrlf\")) {\n+\t\tif (value && !strcasecmp(value, \"warn\")) {\n+\t\t\tsafe_crlf = SAFE_CRLF_WARN;\n+\t\t\treturn 0;\n+\t\t}\n+\t\tsafe_crlf = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \tif (!strcmp(var, \"user.name\")) {\n \t\tstrlcpy(git_default_name, value, sizeof(git_default_name));\n \t\treturn 0;\ndiff --git a/convert.c b/convert.c\nindex 4df7559..598cf0b 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -132,6 +132,27 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\t\t\t*dst++ = c;\n \t\t} while (--len);\n \t}\n+\tif (safe_crlf) {\n+\t\tif ((action == CRLF_INPUT) || auto_crlf <= 0) {\n+\t\t\t/* autocrlf=input: check if we removed CRLFs */\n+\t\t\tif (buf->len != dst - buf->buf) {\n+\t\t\t\tif (safe_crlf == SAFE_CRLF_WARN)\n+\t\t\t\t\twarning(\"Stripped CRLF from %s.\", path);\n+\t\t\t\telse\n+\t\t\t\t\tdie(\"Refusing to strip CRLF from %s.\", path);\n+\t\t\t}\n+\t\t} else {\n+\t\t\t/* autocrlf=true: check if we had LFs (without CR) */\n+\t\t\tif (stats.lf != stats.crlf) {\n+\t\t\t\tif (safe_crlf == SAFE_CRLF_WARN)\n+\t\t\t\t\twarning(\n+\t\t\t\t\t \"Checkout will replace LFs with CRLF in %s\", path);\n+\t\t\t\telse\n+\t\t\t\t\tdie(\"Checkout would replace LFs with CRLF in %s\", path);\n+\t\t\t}\n+\t\t}\n+\t}\n+\n \tstrbuf_setlen(buf, dst - buf->buf);\n \treturn 1;\n }\ndiff --git a/environment.c b/environment.c\nindex 18a1c4e..e351e99 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -35,6 +35,7 @@ int pager_use_color = 1;\n char *editor_program;\n char *excludes_file;\n int auto_crlf = 0;\t/* 1: both ways, -1: only when adding git objects */\n+enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n \n /* This is set by setup_git_dir_gently() and/or git_default_config() */\n-- \n1.5.4.rc2.60.g46ee\n"},{"id":"65208","messageId":"20080112191429.GI2963@dpotapov.dyndns.org","threadId":"11505","inReplyTo":"12001604531066-git-send-email-prohaska@zib.de","subject":"Re: [PATCH] [WIP] safecrlf: Add mechanism to warn about irreversible crlf conversions","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-12T19:14:29Z","receivedAt":"2008-01-12T19:14:29Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, Jan 12, 2008 at 06:54:13PM +0100, Steffen Prohaska wrote:\n> diff --git a/convert.c b/convert.c\n> index 4df7559..598cf0b 100644\n> --- a/convert.c\n> +++ b/convert.c\n> @@ -132,6 +132,27 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n> \t\t\t\t*dst++ = c;\n> \t\t} while (--len);\n> \t}\n> +\tif (safe_crlf) {\n> +\t\tif ((action == CRLF_INPUT) || auto_crlf <= 0) {\n> +\t\t\t/* autocrlf=input: check if we removed CRLFs */\n> +\t\t\tif (buf->len != dst - buf->buf) {\n> +\t\t\t\tif (safe_crlf == SAFE_CRLF_WARN)\n> +\t\t\t\t\twarning(\"Stripped CRLF from %s.\", path);\n> +\t\t\t\telse\n> +\t\t\t\t\tdie(\"Refusing to strip CRLF from %s.\", path);\n> +\t\t\t}\n\nThis check is okay, however\n\n> +\t\t} else {\n> +\t\t\t/* autocrlf=true: check if we had LFs (without CR) */\n> +\t\t\tif (stats.lf != stats.crlf) {\n> +\t\t\t\tif (safe_crlf == SAFE_CRLF_WARN)\n> +\t\t\t\t\twarning(\n> +\t\t\t\t\t \"Checkout will replace LFs with CRLF in %s\", path);\n> +\t\t\t\telse\n> +\t\t\t\t\tdie(\"Checkout would replace LFs with CRLF in %s\", path);\n> +\t\t\t}\n> +\t\t}\n\nthis is not, because if you really want to be sure that file will not be mangled\nby checkout, you should not allow a text file with naked LF when autocrlf=true.\nAnd the following lines after gather_stats() can cause:\n\n\t\t/* No CR? Nothing to convert, regardless. */\n\t\tif (!stats.cr)\n\t\t\treturn 0;\n\nSo, I propose a slightly different patch for convert.c:\n\ndiff --git a/convert.c b/convert.c\nindex 4df7559..9fd88d9 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -90,9 +90,6 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\treturn 0;\n \n \tgather_stats(src, len, &stats);\n-\t/* No CR? Nothing to convert, regardless. */\n-\tif (!stats.cr)\n-\t\treturn 0;\n \n \tif (action == CRLF_GUESS) {\n \t\t/*\n@@ -108,8 +105,23 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\t */\n \t\tif (is_binary(len, &stats))\n \t\t\treturn 0;\n+\n+\t\tif (safe_crlf) {\n+\t\t\t/* check if we have \"naked\" LFs */\n+\t\t\tif (stats.lf != stats.crlf) {\n+\t\t\t\tif (safe_crlf == SAFE_CRLF_WARN)\n+\t\t\t\t\twarning(\n+\t\t\t\t\t \"Checkout will replace LFs with CRLF in %s\", path);\n+\t\t\t\telse\n+\t\t\t\t\tdie(\"Checkout would replace LFs with CRLF in %s\", path);\n+\t\t\t}\n+\t\t}\n \t}\n \n+\t/* No CR? Nothing to convert, regardless. */\n+\tif (!stats.cr)\n+\t\treturn 0;\n+\n \t/* only grow if not in place */\n \tif (strbuf_avail(buf) + buf->len < len)\n \t\tstrbuf_grow(buf, len - buf->len);\n@@ -131,6 +143,16 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\t\tif (! (c == '\\r' && (1 < len && *src == '\\n')))\n \t\t\t\t*dst++ = c;\n \t\t} while (--len);\n+\n+\t\tif (safe_crlf && (action == CRLF_INPUT || auto_crlf <= 0)) {\n+\t\t\t/* autocrlf=input: check if we removed CRLFs */\n+\t\t\tif (buf->len != dst - buf->buf) {\n+\t\t\t\tif (safe_crlf == SAFE_CRLF_WARN)\n+\t\t\t\t\twarning(\"Stripped CRLF from %s.\", path);\n+\t\t\t\telse\n+\t\t\t\t\tdie(\"Refusing to strip CRLF from %s.\", path);\n+\t\t\t}\n+\t\t}\n \t}\n \tstrbuf_setlen(buf, dst - buf->buf);\n \treturn 1;\n\n\nDmitry\n"},{"id":"65234","messageId":"12002151022583-git-send-email-prohaska@zib.de","threadId":"11505","inReplyTo":"20080112191429.GI2963@dpotapov.dyndns.org","subject":"[WIP v2] safecrlf: Add mechanism to warn about irreversible crlf conversions","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-01-13T09:05:02Z","receivedAt":"2008-01-13T09:05:02Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"This version gets the naked LF/autocrlf=true case right.\nHowever, different from what Dimitry suggested, the safety check\nis run for all cases that are irreversible. Dimitry suggested to\nrun it only for the CRLF_GUESS case. I believe this is not\nsufficient: the explicit CFLF_TEXT case should also be checked.\nThe user explicitly marked the file as text but the conversion is\nnonetheless irreversible in the current setting. This might be\nunexpected and we should warn about it. Paranoid users can even\nask git to fail in this case. Such users would need to manually\nfix the file, e.g. running dos2unix.\n\nI also added basic tests.\n\nA documentation is yet missing.\n\n Steffen\n\n---- snip snap ---\n\nCRLF conversion bears a slight chance of corrupting data.\nautocrlf=true will convert CRLF to LF during commit and LF to\nCRLF during checkout. A file that containes a mixture of LF and\nCRLF before the commit cannot be recreated by git. For text\nfiles this does not really matter because we do not care about\nthe line endings anyway; but for binary files that are\naccidentally classified as text the conversion can result in\ncorrupted data.\n\nIf you recognize such corruption during commit you can easily fix\nit by setting the conversion type explicitly in .gitattributes.\nRight after committing you still have the original file in your\nwork tree and this file is not yet corrupted.\n\nHowever, in mixed Windows/Unix environments text files quite\neasily can end up containing a mixture of CRLF and LF line\nendings and git should handle such situations gracefully. For\nexample a user could copy a CRLF file from Windows to Unix and\nmix it with an existing LF file there. The result would contain\nboth types of line endings.\n\nUnfortunately, the desired effect of cleaning up text files\nwith mixed lineendings and undesired effect of corrupting binary\nfiles can not be distinguished. In both cases CRLF are removed\nin an irreversible way. For text files this is the right thing\nto do, while for binary file its corrupting data.\n\nIn a sane environment committing and checking out the same file\nshould not modify the origin file in the work tree. For\nautocrlf=input the original file must not contain CRLF. For\nautocrlf=true the original file must not contain LF without\npreceding CR. Otherwise the conversion is irreversible. Note,\ngit might be able to recreate the original file with different\nautocrlf settings, but in the current environment checking out\nwill yield a file that differs from the file before the commit.\n\nThis patch adds a mechanism that can either warn the user about\nan irreversible conversion or can even refuse to convert. The\nmechanism is controlled by the variable core.safecrlf, with the\nfollowing values\n - false: disable safecrlf mechanism\n - warn: warn about irreversible conversions\n - true: refuse irreversible conversions\n\nThe default is to warn.\n\nThe concept of a safety check was originally proposed in a similar\nway by Linus Torvalds. Thanks to Dimitry Potapov for insisting\non getting the naked LF/autocrlf=true case right.\n\nSigned-off-by: Steffen Prohaska \n---\n cache.h | 8 ++++++++\n config.c | 9 +++++++++\n convert.c | 28 +++++++++++++++++++++++++---\n environment.c | 1 +\n t/t0020-crlf.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++\n 5 files changed, 88 insertions(+), 3 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 39331c2..4e03e3d 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -330,6 +330,14 @@ extern size_t packed_git_limit;\n extern size_t delta_base_cache_limit;\n extern int auto_crlf;\n \n+enum safe_crlf {\n+\tSAFE_CRLF_FALSE = 0,\n+\tSAFE_CRLF_FAIL = 1,\n+\tSAFE_CRLF_WARN = 2,\n+};\n+\n+extern enum safe_crlf safe_crlf;\n+\n #define GIT_REPO_VERSION 0\n extern int repository_format_version;\n extern int check_repository_format(void);\ndiff --git a/config.c b/config.c\nindex 857deb6..0a46046 100644\n--- a/config.c\n+++ b/config.c\n@@ -407,6 +407,15 @@ int git_default_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.safecrlf\")) {\n+\t\tif (value && !strcasecmp(value, \"warn\")) {\n+\t\t\tsafe_crlf = SAFE_CRLF_WARN;\n+\t\t\treturn 0;\n+\t\t}\n+\t\tsafe_crlf = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \tif (!strcmp(var, \"user.name\")) {\n \t\tstrlcpy(git_default_name, value, sizeof(git_default_name));\n \t\treturn 0;\ndiff --git a/convert.c b/convert.c\nindex 4df7559..c9678ee 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -90,9 +90,6 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\treturn 0;\n \n \tgather_stats(src, len, &stats);\n-\t/* No CR? Nothing to convert, regardless. */\n-\tif (!stats.cr)\n-\t\treturn 0;\n \n \tif (action == CRLF_GUESS) {\n \t\t/*\n@@ -110,6 +107,20 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\t\treturn 0;\n \t}\n \n+\tif (safe_crlf && auto_crlf > 0 && action != CRLF_INPUT) {\n+\t\t/* CRLFs would be added by checkout: check if we have \"naked\" LFs */\n+\t\tif (stats.lf != stats.crlf) {\n+\t\t\tif (safe_crlf == SAFE_CRLF_WARN)\n+\t\t\t\twarning(\"Checkout will replace LFs with CRLF in %s\", path);\n+\t\t\telse\n+\t\t\t\tdie(\"Checkout would replace LFs with CRLF in %s\", path);\n+\t\t}\n+\t}\n+\n+\t/* Optimization: No CR? Nothing to convert, regardless. */\n+\tif (!stats.cr)\n+\t\treturn 0;\n+\n \t/* only grow if not in place */\n \tif (strbuf_avail(buf) + buf->len < len)\n \t\tstrbuf_grow(buf, len - buf->len);\n@@ -132,6 +143,17 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\t\t\t*dst++ = c;\n \t\t} while (--len);\n \t}\n+\n+\tif (safe_crlf && (action == CRLF_INPUT || auto_crlf <= 0)) {\n+\t\t/* CRLFs would not be restored by checkout: check if we removed CRLFs */\n+\t\tif (buf->len != dst - buf->buf) {\n+\t\t\tif (safe_crlf == SAFE_CRLF_WARN)\n+\t\t\t\twarning(\"Stripped CRLF from %s.\", path);\n+\t\t\telse\n+\t\t\t\tdie(\"Refusing to strip CRLF from %s.\", path);\n+\t\t}\n+\t}\n+\n \tstrbuf_setlen(buf, dst - buf->buf);\n \treturn 1;\n }\ndiff --git a/environment.c b/environment.c\nindex 18a1c4e..e351e99 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -35,6 +35,7 @@ int pager_use_color = 1;\n char *editor_program;\n char *excludes_file;\n int auto_crlf = 0;\t/* 1: both ways, -1: only when adding git objects */\n+enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n \n /* This is set by setup_git_dir_gently() and/or git_default_config() */\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex 89baebd..e2e0f7b 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -8,6 +8,10 @@ q_to_nul () {\n \ttr Q '\\000'\n }\n \n+q_to_cr () {\n+\ttr Q '\\015'\n+}\n+\n append_cr () {\n \tsed -e 's/$/Q/' | tr Q '\\015'\n }\n@@ -42,6 +46,47 @@ test_expect_success setup '\n \techo happy.\n '\n \n+test_expect_failure 'safecrlf: autocrlf=input, all CRLF' '\n+\n+\tgit repo-config core.autocrlf input &&\n+\tgit repo-config core.safecrlf true &&\n+\n+\tfor w in I am all CRLF; do echo $w; done | append_cr >allcrlf &&\n+\tgit add allcrlf\n+'\n+\n+test_expect_failure 'safecrlf: autocrlf=input, mixed LF/CRLF' '\n+\n+\tgit repo-config core.autocrlf input &&\n+\tgit repo-config core.safecrlf true &&\n+\n+\tfor w in Oh here is CRLFQ in text; do echo $w; done | q_to_cr >mixed &&\n+\tgit add mixed\n+'\n+\n+test_expect_failure 'safecrlf: autocrlf=true, all LF' '\n+\n+\tgit repo-config core.autocrlf true &&\n+\tgit repo-config core.safecrlf true &&\n+\n+\tfor w in I am all LF; do echo $w; done >alllf &&\n+\tgit add alllf\n+'\n+\n+test_expect_failure 'safecrlf: autocrlf=true mixed LF/CRLF' '\n+\n+\tgit repo-config core.autocrlf true &&\n+\tgit repo-config core.safecrlf true &&\n+\n+\tfor w in Oh here is CRLFQ in text; do echo $w; done | q_to_cr >mixed &&\n+\tgit add mixed\n+'\n+\n+test_expect_success 'switch off autocrlf, safecrlf' '\n+\tgit repo-config core.autocrlf false &&\n+\tgit repo-config core.safecrlf false\n+'\n+\n test_expect_success 'update with autocrlf=input' '\n \n \trm -f tmp one dir/two three &&\n-- \n1.5.4.rc2.60.g46ee\n"},{"id":"65309","messageId":"871w8kvj57.fsf@lysator.liu.se","threadId":"11505","inReplyTo":"alpine.LFD.1.00.0801111005360.3148@woody.linux-foundation.org","subject":"Re: CRLF problems with Git on Win32","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2008-01-14T09:41:40Z","receivedAt":"2008-01-14T09:41:40Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 11 Jan 2008, Steffen Prohaska wrote:\n>> \n>> Ah sorry, I misunderstood you in [1]. I thought your last point\n>> \"Mixed Windows usage\" meant what I have in mind: A user working\n>> in a mixed Windows/Unix environment who creates a file using\n>> Windows tools and commits it in the Unix environment. In this\n>> case the CRLF file will be transferred from Windows to Unix\n>> without git being involved. The right thing for git on Unix is\n>> to remove CRLF during a commit but still write only LF during\n>> check out. So autocrlf=input is the right choice.\n>\n> Oh, ok, I didn't realize.\n>\n> But yes, if you use a network share across windows and Unixand actually \n> *share* the working tree over it, then yes, you'd want \"autocrlf=input\" on \n> the unix side.\n>\n> However, I think that falls under the \"0.1%\" case, not the \"99.9%\" case.\n>\n> I realize that people probably do that more often with centralized \n> systems, but with a distributed thing, it probably makes a *ton* more \n> sense to have separate trees. But I could kind of see having a shared \n> development directory and accessing it from different types of machines \n> too.\n\nOne case is when you only want to commit compiling code, and to\ntest-compile on all platforms that you are supposed to be portable to\nyou need to access the source tree on different systems before\ncommitting anything.\n\nYou could of course commit optimistically and checkout on the other\nsystem, and then go back and rewrite the commits if you need to fix\nsomething. But that is a lot more work.\n\n-- \nDavid Kågedal\n"}]}