Everything good about Python except GUI IDE?

[Chris Angelico]

On Mon, Feb 29, 2016 at 11:39 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> If I open a Python file in my editor, accidentally or deliberately change
> the content to Ruby code, save and commit, then the VCS obviously should
> track the changes because they are actual changes.

"Oops, I accidentally pressed Esc-Meta-Alt-R-Q and translated my code
into Ruby. Now what?"

> Changing line endings is neither a structural nor a semantic change to the
> content of the file. It's effectively metadata, not data. The Python
> interpreter doesn't care which line ending you use. Neither will decent
> text editors. If some tools, like git, do, then that's a weakness of git,
> not a feature. Changing the permissions on a 10,000 line file doesn't give
> you a 10,000 line diff, and neither should changing the line ending.
>
> Your VCS absolutely should track line ending changes. In a perfect world, we
> should never care about the line ending, but so long as there are users and
> tools that cannot transparently deal with one line ending or another, there
> may be times were we do care about line endings, and therefore want to
> run "git blame" to find out which idiot changed the line ending of my file
> to \r. But that should be treated as a metadata change, not a change to the
> content. I know it isn't "really" metadata, it's "actually" content, but
> regardless, it should be *treated* as metadata.
>
> Who is the boss here? The user of the tool, or the tool?

This is a tricky question, and there's a slight difference between
perms and line endings in that it's perfectly possible to have mixed
line endings. The normal way to resolve this is to tell git to convert
line endings *for text files* such that source control always uses \n,
and then individual users get to choose whether to check out with \n
or convert to \r\n for their working copies. This destroys any
information that had been represented in mixed line endings - but
that's information that no project I've ever worked with uses.
However, since this is not something that git dares do on its own,
it's not the default action - though the Git Windows installer does
prompt you to pick those options on installation.

Once you tell git to treat line endings the same way ("git config
--global core.autocrlf true", if memory serves me), it's not even
metadata, it's just non-information.

ChrisA