Fix the .gitattributes so that line endings are correct on all platforms

[pmetzger]

Currently, checkouts of the code result in source code having CRLF line endings even on Unix systems.

This is almost certainly because of misconfiguration of the .gitattributes file.

It would be good to get this fixed; it plays havoc with some editors.

[bscottm]

@pmetzger: Preferably, open-simh should normalize line endings across the code, remove the line endings hack from .gitattributes and require those who need CRLF line endings to set the appropriate git --config --local setting. IMHO.

[pkoning2]

I'm not sure what .gitattributes hack you're talking about; the .gitattributes file makes no mention of source files.

Open SIMH by convention uses CRLF line endings. I'm not entirely sure why, but that's what it has done as long as I know of, and the coding standard is to keep it that way. I can believe that some primitive editors can't cope with this; if so, you'll have to switch to a better editor, or post-process files you edit to force the line endings to CRLF. Emacs, as usual, gets this right.

[pmetzger]

So, git by default is capable of handling line endings just fine, so everyone checking out and checking in is completely unaware of distinctions between different platforms. (It also detects binaries and text files by default.)

The .gitattributes file include several kinds of text files in it (such as *.vcproj) as binary; this may be why it is doing as it does, or it may be that the repo needs a --renormalize; I'm not sure.

However, the current behavior is very anomalous. Essentially all projects shared between Unix and Windows via git make all this transparent; SIMH is unusual.

[bscottm]

So, git by default is capable of handling line endings just fine, so everyone checking out and checking in is completely unaware of distinctions between different platforms. (It also detects binaries and text files by default.)

I'm in "violent agreement" with you about normalizing the line endings and leaving source line endings as a local configuration decision. (@pkoning2: At one point or another, I could swear I saw a hack for *.c and *.h files in the .gitattributes file.)

If line endings are renormalized, I highly recommend adding *.c and *.h to the .gitattributes file so that they are explicitly marked as text files. Hard to get things wrong when they are explicit.

[markpizz]

This has been discussed several times before.

As @pkoning2 said: Open SIMH by convention uses CRLF line endings. I'm not entirely sure why, but that's what it has done as long as I know of, and the coding standard is to keep it that way.

What you're talking about is NOT merely changing something in .gitattributes, BUT changing EVERY text file in the simh repo. Folks on the steering committee decided that changing everything wouldn't be a good idea.

I hope me participating in this conversation isn't offensive to anyone.

[pkoning2]

Thanks Mark, that's fine.

From what I understand, Git, unlike Subversion, does not typically "normalize" text files in the repository, converting them to/from OS-flavored formats on checkout and commit. So instead, we currently have the text files, with CRLF line endings, in the repository. If we change that, the result is that every file changes (simply because its line endings in the repository change). In the same way that bulk changes in spacing or indentation are discouraged, that isn't something we think is desirable.

A possible solution would be to have a pre-commit hook that enforces the line endings rule. I don't have the git skills for that, but I suppose I could learn.

[bscottm]

@markpizz: IIRC, it was a matter of the number of changes that would suddenly appear when sim devs pulled the master branch. If open-simh decides to renormalize, it needs to be rolled out with a lot of fanfare on the simh mailing list. Let people know it's coming. Reiterate that it's going to arrive. Tell people what they need to do once it arrives. Count down to arrival day, reminding people that it's coming and what they need to do. Then renormalize the repo.

[markpizz]

IIRC, it was a matter of the number of changes that would suddenly appear when sim devs pulled the master branch.

Actually it was all about change history in every module, the vast majority of which haven't changed in decades.

Simulator developers likely look at these things and would certainly be bother by noise changes that these would be. ALL of these developers have managed (again for decades) to live with the project standard of CR line endings.

[pmetzger]

If we change that, the result is that every file changes (simply because its line endings in the repository change).

That is not necessary. It is happy just checking out on every platform with the local line endings. You just have to tell it to do that in the .gitattributes. Try it!

[pkoning2]

If we change that, the result is that every file changes (simply because its line endings in the repository change).

That is not necessary. It is happy just checking out on every platform with the local line endings. You just have to tell it to do that in the .gitattributes. Try it!

I see that part in the docs, but what I meant isn't as clearly documented. Pro Git has some more details. It's still amazingly baffling, as is so often the case with the more advanced Git features. The key question: if we were to set this, what happens to the files in the repository? Do they all change? Do they change (to have LF-only as the internal form) only when a new version is committed? In either case, will "git diff" show all lines as changed, or are lines where nothing changed apart from the EOL form appear unchanged?

If the answer is "nothing changes except in a file that is modified, and for such files only "real" changes are visible" that would be a good option. I can do some experiments in a test repository. If all looks good we can talk about it some more.

[bscottm]

If we change that, the result is that every file changes (simply because its line endings in the repository change).

That is not necessary. It is happy just checking out on every platform with the local line endings. You just have to tell it to do that in the .gitattributes. Try it!

@pmetzger "text" in .gitattributes implies renormalized line endings and git autocrlf is set properly in the first place. Hence renormalizing the code base. At least in my humble experience.