add .gitattributes

[jmjatlanta]

This fixes #1754

By controlling how git handles text files on Windows, we can assure that the correct chain id gets generated.

Note: This change causes that all text files cloned by git are saved with LF, instead of the Windows standard CRLF. I believe there are no problems in permitting all files to retain their standard non-Windows encoding. But should this cause problems in some area, the .gitattributes file can be modified to control which line endings are applied to which files.

[pmconrad]

Not sure if anyone is developing on mac or windows, nor what tools they are using, but I think most files should be in native encoding.
I know some editors on windows do not handle files with LF endings properly.
I also know that some sh implementations on windows choke on shell scripts with CRLF endings.

Opinions from mac/windows experts?

[abitmore]

Replace * with genesis.json?

I guess this would work:

genesis.json -text

I don't think it's good to have text and eol at the same time, since they're conflicting. See https://git-scm.com/docs/gitattributes

text

Set
Setting the text attribute on a path enables end-of-line normalization and marks the path as a text file. End-of-line conversion takes place without guessing the content type.

Unset
Unsetting the text attribute on a path tells Git not to attempt any end-of-line conversion upon checkin or checkout.

eol
This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line conversion without any content checks, effectively setting the text attribute.

[jmjatlanta]

macOS uses LF, not CRLF.

I agree that we should only translate what is necessary. I was hoping to catch any commits with CRLF and convert them to LF, but that may be overly ambitious. And as you say, may cause grief in some editors.

It is my understanding that genesis.json text=unset will prevent the translation, even if somehow a CRLF gets into github for that file. Whereas genesis.json eol=lf will bring down genesis.json, translating CRLF to LF if necessary. I will test it out.

Update: I tested it, and it works. I even attempted an add, and when adding the file (which was already mentioned in the .gitattributes file), it displayed:

warning: CRLF will be replaced by LF in my_directory/myfile_crlf.txt.
The file will have its original line endings in your working directory

[abitmore]

Windows, and DOS before it, uses a pair of CR and LF characters to terminate lines. UNIX (Including Linux and FreeBSD) uses an LF character only. OS X also uses a single LF character, but the classic Mac operating system used a single CR character for line breaks. https://www.editpadpro.com/tricklinebreak.html

[pmconrad]

I don't think it's good to have text and eol at the same time, since they're conflicting.

In my understanding there is no conflict (except that -text and eol on the same file is contradictory).

Normally, git tries to automatically detect if a file is a text file or a binary. If git thinks it's a text file it may apply certain conversions on checkout and commit whereas for binaries it doesn't. The text attribute merely overrides this automatic detection with an explicit setting.

Now, the eol attribute (and config settings like autocrlf) apply only to files that are to be treated as text files. They specify what kind of conversion is to be applied.

genesis.json should not be modified at all, so I agree that the appropriate setting for this would be -text.

Question is, should we set text=auto on certain file patterns? Like *.cpp, *.hpp, *.md etc.?

[abitmore]

Question is, should we set text=auto on certain file patterns? Like *.cpp, *.hpp, *.md etc.?

Aren't they auto already?

[pmconrad]

Aren't they auto already?

In my understanding this depends on the user's local git configuration core.autocrlf by default. With text=auto we would enforce it. I may be wrong though.

[jmjatlanta]

It is my understanding that the following line does what we want:

genesis.json eol=lf

Interpretation: Handle all files in the typical way, with the exception of the genesis.json file. For that file, assure that the lf remains lf, and does not get converted to crlf for Windows users.

If the user has their [core] settings in any configuration, that is their preference, and should not affect BitShares. We are only requiring that genesis.json remain a certain way regardless of the platform.

[pmconrad]

Ok, I think consensus is to not add settings for any other files except genesis.json.

For genesis.json, both -text or eol=lf should produce identical results at this time, so I don't care which it is.