Not working correctly on Update 1

[SteveALee]

I do not know if it worked correctly before but currently with this config

# This file is for unifying the coding style for different editors and IDEs.
# EditorConfig http://EditorConfig.org
# In VisualStudio use the EditorConfig extension - https://visualstudiogallery.msdn.microsoft.com/c8bccfe2-650c-4b42-bc5c-845e21f96328

# top-most EditorConfig file
root = true

# unix style line endings with a newline ending every file
# Line-ending will interact with git line ending transformation processing
[*]
indent_style = space
indent_size = 4
end_of_line = lf
insert_final_newline = true
charset = utf-8
trim_trailing_whitespace = true

[Makefile]
indent_style = tab

#[{package.json,.travis.yml}]
#indent_size = 2

If I create edit and save a new txt file file (in git for windows) says it is

TextFile2.txt:   ASCII text, with CRLF line terminators

not LF line endings

if I insert áá it becomes ISO-8859 not UTF-8

[SteveALee]

PS also a lot of my files appear as UTF-8 BOM but I did not use that option. Possibly I created in another editor.

[jednano]

The charset setting is not supported in the Visual Studio plugin.

Also, I'm confused by you stating that you created, edited and saved a new txt file in Git for Windows.

1. How do you create a txt file in Git for Windows?
2. How do you edit and save a txt file in Git for Windows?

What tool is reporting ASCII text, with CRLF line terminators?

What happens if you run the EditorConfig CLI tool on your file? What does it say your configuration is then?

[SteveALee]

@jedmao

Also, I'm confused by you stating that you created, edited and saved a new txt file in Git for Windows. 1.How do you create a txt file in Git for Windows? 2.How do you edit and save a txt file in Git for Windows?

What tool is reporting ASCII text, with CRLF line terminators ?

Sorry - that was terrible text.

I created the file in visual studio (as a new txt file) and then used the file command in git for windows. This shows the info I listed. eg file

Also I found I had disabled EditorConfig as trying to get to a crash bug. After enabling I found no change. From what you say we expect that the chatset won't work, but shouldn't 'line_ending' work?

I was not aware there was a command line tool. I'll go find and try it.

I was hoping to force lf line endings for everything on Windows and set .gitattributes to do no CRLF translations. On reflection that's too dangerous as any other editor used to create files might not start with LF only, even if they don't change existing line endings.

[SteveALee]

@jedmao hmm, no sign of the cli tool on http://editorconfig.org/ ?

[jednano]

@SteveALee you can find editorconfig on npm, which means you can $ npm install -g editorconfig to gain access to the CLI tool.

Visual Studio always adds BOMs to new files, which is why you're getting those. From my research, there's no way to change this or I would have by now. Besides, I'm using Visual Studio less and less these days, in favor of Sublime Text and now the open source Visual Studio Code.

Yes. The end_of_line setting should definitely work. This is where I would suggest using the CLI tool to verify the settings for the file in question actually get the lf setting.

As for .gitattributes, what you're looking for is:

*  eol=lf

The above setting doesn't care what people's line endings are on their local machines, but it always ensures LF line endings are submitted to the repo.

[SteveALee]

@jedmao Thanks again for the extra info

you can find editorconfig on npm,

Aha - a mention would be useful on the web page :)

Visual Studio always adds BOMs to new files, which is why you're getting those. From my research, there's no way to change this or I would have by now

Ugh!. At least it falls back to ASCII if it can with new files. I used notepad++ to change encoding but seems like that's a waste of energy from what you say.

I'm using Visual Studio less and less these days, in favor of Sublime Text and now the open source Visual Studio Code.

Code is really excellent for edit/debug cycle but only supports a few EditorConfig features. I requested they add it when it launched and got a feature alert recently saying they have an EditorConfig extension that supports indent only. Good news is charset is on the roadmap. Now it's open source perhaps they will accept a PR and include it in the product too?

Yes. The end_of_line setting should definitely work

OK I'll re check. Are changes to the config file immediately used or do we need to restart VS?

*  eol=lf

The above setting doesn't care what people's line endings are on their local machines, but it always ensures LF line endings are submitted to the repo.

Oh, if only it was that simple :( Current behaviour is that setting eol implies text so what you suggest makes ALL files treated as text. That means on check in any CRLFs are normalised to LF and on checkout the LF remains. Thus any binary files are corrupt with an checkin/out cycle. The only solution currently is to explicitly list all text or all binary files in .gitattributes, not a major pain but it is error prone and hard to undo a corruption. And no * text=auto cr=lf doesn't work as you'd like.

I think * -text is the best option but leaves all files in whatever state they are created in (like SVN). As long a no CRLFs are created that is good enough for sharing with users on *nix or in a VM.

Microsoft's decision to have text and binary modes with text EOLs as CRLF in MS-DOS is one of those massive pain points that just won't die. Same with MAX_PATH.

[SteveALee]

@jedmao

Yes. The end_of_line setting should definitely work

It does.. Other errors must have been interfering at the time. Apologies.

The CLI version of editorconfig is great but I see it does not show charset. Still need to use file for that.

[jednano]

@SteveALee I wouldn't advocate the use of * text=auto in tandem with EditorConfig's end_of_line setting until if/when end_of_line = native is implemented. See this issue. Until then, I suggest * eol=lf and then targeting any binary files with *.jpg binary and such.

As for the CLI, I'm not sure what you're expecting, but EditorConfig will never show you the actual charset of a file. It will only tell you the EditorConfig configuration for that file. I just tested it here and everything works perfectly well. I have an .editorconfig file with:

[*]
charset = utf8

And I run:

$editorconfig package.json

And it shows me:

charset=utf8

The changes to the config file are immediate, but only if you lose focus and re-focus to a tab. That's when the EditorConfig triggers, or when you open a new file.

The VSCode plugin is definitely new. I've already started contributing to it, but it looks like the project owner is on vacation for now. We'll see what happens when he gets back.

I'm closing this issue now, as I believe the original issue is resolved.

[SteveALee]

@jedmao

Until then, I suggest * eol=lf and then targeting any binary files with *.jpg binary

:+1: Given a) open source project so can't control tooling used and b) few non text files are checked in. Can probably live with a few extra checkins with all lines changed from CRLF to LF, though may bite some folks

The VSCode plugin is definitely new. I've already started contributing to it, but it looks like the project owner is on vacation for now. We'll see what happens when he gets back.

:clap:

Thanks again for help.

[jednano]

I understand that you can't control the tooling used. That's why * eol=lf works so great, because the repo always has consistent line endings. How is it going to bite some folks? It would only hurt if you failed to mark a particular file as binary, which if that happens, you fix the issue in the .gitattributes file and move on.

OK. Actually, I can think of only one way it may bite some folks. Say you modify a file with all LF line endings and then you add some CRLF line endings. Next time you open the file it may prompt you that there are mixed line endings and ask you if you want to fix them or not. Fortunately, these types of dialogues have a "Never ask me again" checkbox, usually, so you can get around that too. Problem is, you might not want to check that checkbox, because "other" projects may not have the .gitattributes file setup the same way.

Really, I can't wait for end_of_line = native. I think this would solve so many problems.

[SteveALee]

How is it going to bite some folks?

You might be correct. I've seen cases when all files get marked as every line changed but that might only be when you changed EOL handling. I thought if you checked in with text or out with eol=lf it detects the CRLFs as changes. Easiest thing is I'll run some tests tomorrow.

Really, I can't wait for end_of_line = native. I think this would solve so many problems.

Yes looks good. I thought not specifying any in the editorconfig got close to that :) But its more end_of_line = tool :)

[jednano]

@SteveALee the first time you change the .gitattributes file to include * eol=lf will potentially be a massive commit, because it will change all line endings on that commit. Every subsequent commit, however, would never have that issue. It's a one time thing, but once you implement the .gitattributes file it keeps things consistent.

[SteveALee]

@jedmao I finally figured what was bugging me about * eol=lf

Any CRLFs in files don't get replaced in your workspace until you checkout and git doesn't think it needs to checkout in my tests (same with the git symbols but I doubt anyone uses then now). Thus what you have in your workspace is different to anyone who clones out and thus potentially hides bugs (very unlikely). ESLint and CI can help detect.

The "end_of_line=native" option for EditorConfig is cool but doesn't help if you share files between a Linux VM and Windows host on which you checkout. Those CRLFs may break something on Linux.

I felt the urge to blog on this

It would be best I think if git supported "* text=auto eol=lf"

[jednano]

@SteveALee I looked into this again and I think I failed to tell you some important steps. See End-of-line conversion for more information, but what you need to do is this:

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

[SteveALee]

Thanks - such a minefield.

[jednano]

Any progress? Curious to know if your problems have been solved.

[SteveALee]

Hey Jed, thanks

• The original problem reported is sorted
• The general CRLF issue remains a pain if sharing files :) I recorded all info I could collect in my blog. Comments welcome
• The crash reported in #32 has effectively gone away for me