Walter Bright wrote:
> 
> 
> Jens Mueller wrote:
> >I'll guess not. Because
> >core.autocrlf = true means
> >"Use this setting if you want to have CRLF line endings in your working
> >directory even though the repository does not have normalized line endings."
> >(see man git-config)
> >
> >See here for further explanation: http://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operati
> >
> >The part "Moving forward" on github seems rather strange to me.
> >
> 
> I tried various settings a few months back, and failed miserably. Nobody I asked could tell me what the various settings actually did, none of the online explanations made any sense (*). My takeaway was:
> 
> 1. do not attempt to use git on Windows
> 2. write tolf.d and fix all line endings to \n before submission to git
> 
> So far, that works.
> 
> 
> (*) First off, there were several settings. Nobody could tell me if git stored the files in its database with canonicalized line endings, what happened to the original files (were they modified by git?) and what happens when files were restored from git (line endings left as is, rewritten, what?), if only the diff programs affected, was the sha hash affected, etc.

Good questions.
Reading the section "Effects" on gitattributes
http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
I think some can be answered. Though I have to admit I never used git on
Windows.

Jens

On Mon, 2011-01-24 at 12:28 -0800, Walter Bright wrote:
> 
> Jens Mueller wrote:
> > I'll guess not. Because
> > core.autocrlf = true means
> > "Use this setting if you want to have CRLF line endings in your working
> > directory even though the repository does not have normalized line endings."
> > (see man git-config)
> >
> > See here for further explanation: http://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operati
> >
> > The part "Moving forward" on github seems rather strange to me.
> >
> > 
> 
> I tried various settings a few months back, and failed miserably. Nobody I asked could tell me what the various settings actually did, none of the online explanations made any sense (*). My takeaway was:
> 
> 1. do not attempt to use git on Windows
> 2. write tolf.d and fix all line endings to \n before submission to git
> 
> So far, that works.
> 
> 
> (*) First off, there were several settings. Nobody could tell me if git stored the files in its database with canonicalized line endings, what happened to the original files (were they modified by git?) and what happens when files were restored from git (line endings left as is, rewritten, what?), if only the diff programs affected, was the sha hash affected, etc.
> 
> Clearly, at a deep fundamental level, git works with binary files. Not
> text files. Attempting to hammer it to work with text files is just doomed.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

The "core.autocrlf" section on http://progit.org/book/ch7-1.html says:

"Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you?re on a Windows machine, set it to true ? this converts LF endings into CRLF when you check out code"

and

"If you?re on a Linux or Mac system that uses LF line endings, then you don?t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input"

Johannes Pfau wrote:
>
> The "core.autocrlf" section on http://progit.org/book/ch7-1.html says:
>
> "Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you?re on a Windows machine, set it to true ? this converts LF endings into CRLF when you check out code"
>
> and
>
> "If you?re on a Linux or Mac system that uses LF line endings, then you don?t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input"
>
> 

Here's what happens - someone checks in CRLF files on Windows. Then I check out the repository on Linux. Now, git status claims that these files are "different" on Linux and need checking in again.

There really is no hope for this, other than ensuring that all source files checked in are LF, nor CRLF, terminated.

Am Dienstag, den 25.01.2011, 01:13 -0800 schrieb Walter Bright:
> 
> Johannes Pfau wrote:
> >
> > The "core.autocrlf" section on http://progit.org/book/ch7-1.html says:
> >
> > "Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you?re on a Windows machine, set it to true ? this converts LF endings into CRLF when you check out code"
> >
> > and
> >
> > "If you?re on a Linux or Mac system that uses LF line endings, then you don?t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input"
> >
> > 
> 
> Here's what happens - someone checks in CRLF files on Windows. Then I check out the repository on Linux. Now, git status claims that these files are "different" on Linux and need checking in again.
> 
> There really is no hope for this, other than ensuring that all source
> files checked in are LF, nor CRLF, terminated.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

If the person on windows has set core.autocrlf = true this will ensure that the checked in files are LF terminated. With core.autocrlf = true CRLF files cannot enter the repository, but it's important that every windows user sets core.autocrlf to true.

If the person on windows hasn't set that variable the CRLF files will enter the repository. If someone on linux with core.autocrlf = input checks out those files they will be fixed to LF endings automatically - which imho is a good thing. Because of that the files will be shown as changed(They now have different line endings as in the repository. This is a change and needs to be commited). If you don't want git to fix that automatically just use core.autocrlf = false on linux.

On 01/25/2011 10:13 AM, Walter Bright wrote:
> There really is no hope for this, other than ensuring that all source files checked in are LF, nor CRLF, terminated.

Is there a programming editor that does not make this trivial --or even automatic via a standard setting?

Also, why doesn't git simply allow abstracting this issue via a simple repo
setting (transparent conversion to an internally used line ending)? Don't loads
of PLs do this?
On checkout, a user-defined setting would possibly convert back; overridable by
a checkout command arg
(for people working on several OSes).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Crazy thought - how about you change your editor to use LF? Operating systems wars aside, this is clearly a place where Windows borked up.

Andrei

On 1/25/11 3:13 AM, Walter Bright wrote:
>
>
> Johannes Pfau wrote:
>>
>> The "core.autocrlf" section on http://progit.org/book/ch7-1.html says:
>>
>> "Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you?re on a Windows machine, set it to true ? this converts LF endings into CRLF when you check out code"
>>
>> and
>>
>> "If you?re on a Linux or Mac system that uses LF line endings, then you don?t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input"
>>
>
> Here's what happens - someone checks in CRLF files on Windows. Then I check out the repository on Linux. Now, git status claims that these files are "different" on Linux and need checking in again.
>
> There really is no hope for this, other than ensuring that all source
> files checked in are LF, nor CRLF, terminated.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Johannes Pfau wrote:
>
> If the person on windows has set core.autocrlf = true this will ensure that the checked in files are LF terminated. With core.autocrlf = true CRLF files cannot enter the repository, but it's important that every windows user sets core.autocrlf to true.
>
> If the person on windows hasn't set that variable the CRLF files will enter the repository. If someone on linux with core.autocrlf = input checks out those files they will be fixed to LF endings automatically - which imho is a good thing. Because of that the files will be shown as changed(They now have different line endings as in the repository. This is a change and needs to be commited). If you don't want git to fix that automatically just use core.autocrlf = false on linux.
>
>
> 

Thanks for the explanation and the tip. But that requires everyone who clones the depository to do this. It should work correctly with a default git install.

Another problem - meld on linux shows every line as different between CRLF and LF files, and there is no option to ignore line ending differences. Working badly with differing line endings is typical for linux programs. (Though to be fair, Windows Notepad can't deal with LF files.)

This is just like the tab situation. Are tabs 3, 4 or 8 characters? There is no solution - the only way is to not use tabs. The most reasonable way forward with git is to never check in CRLF files. I've added detab and tolf to my workflow, and I ask everyone else to who edits files on Windows as well.

Andrei Alexandrescu wrote:
> Crazy thought - how about you change your editor to use LF? Operating systems wars aside, this is clearly a place where Windows borked up.

I've integrated tolf into my workflow. The CRLF files checked in were not done by myself.

The Windows use of CRLF goes back to DOS, based on CP/M, which derived from DEC RT-11, which derived from DEC SYSTEM-10 in use in the 70's. So it goes back at least that far, probably much farther. All DEC operating systems used CRLF.

It obviously goes back at least as far as ASCII itself. LF means "line feed", which advances the platen one line. CR means "carriage return" which moves the print head to the beginning of the line. These are separate operations, and a lot of older programs relied on it. ASCII terminals (and teletypes) all operated this way.

To say that Windows clearly borked it up is very incorrect.

Windows has a lot of DEC heritage in it, including how the command line interface works, even the names of a lot of the commands, like TYPE.

On Tue, Jan 25, 2011 at 10:46 AM, Walter Bright <walter at digitalmars.com> wrote:

> Another problem - meld on linux shows every line as different between CRLF and LF files, and there is no option to ignore line ending differences. Working badly with differing line endings is typical for linux programs. (Though to be fair, Windows Notepad can't deal with LF files.)

Found this:

"In the Text Filters preferences page, add a new filter with a name something like 'CRLF line ending' and the regex '\r+$'; enable it, then restart meld to get the setting picked up when comparing a directory tree."

Jesse Phillips wrote:
> On Tue, Jan 25, 2011 at 10:46 AM, Walter Bright <walter at digitalmars.com> wrote:
>
> 
>> Another problem - meld on linux shows every line as different between CRLF
>> and LF files, and there is no option to ignore line ending differences.
>> Working badly with differing line endings is typical for linux programs.
>> (Though to be fair, Windows Notepad can't deal with LF files.)
>> 
>
> Found this:
>
> "In the Text Filters preferences page, add a new filter with a name something like 'CRLF line ending' and the regex '\r+$'; enable it, then restart meld to get the setting picked up when comparing a directory tree."
>
> 

Works great! Thanks!