Asset server content hashing may mismatch based on platform line endings

[MaxCWhitehead]

In Jumpy, have seen CRLF on windows in assets like maps, and macOS/Linux LF, which causes mismatch in CIDs.

Wondering if we may want to add an option to FileAssetIO to force converting to linux line endings when reading asset bytes, though would need to makes sure this is only applied on text files.

Related: fishfolk/jumpy#995

[zicklag]

I'm wondering if maybe a better alternative is to configure git to not switch the line endings on different platforms. I'm pretty sure that's a git feature that does that.

VSCode should support the linux line endings fine even on Linux, and I think it makes the most sense that the assets shouldn't be modified by git on a per-platform basis.

[MaxCWhitehead]

Yeah I think that sounds like a decent bet - detecting text files and processing them seems dicey.

I do worry a bit about user created assets that may not be in a repo configured this way, but we can cross that bridge when we get there / provide some lint or warnings on externally loaded assets with CRLF if need be.

[MaxCWhitehead]

It looks like .gitattributes may work on reprository level on checkout to override client config. I'll test this, and take a look at our windows packaging process and make sure that ends up with right settings as well.

[zicklag]

Yeah, that looked like the way you're supposed to configure it. The only thing that bugged me is that we have to add an explicit mention in that file for each kind of text file extension that we use as an asset. But that's really not that big a deal probably.

[MaxCWhitehead]

I got away without specifying yaml or specific extensions, it seemed to resolve the issue. Folks with current CRLF checkouts will need to follow instructions on that page to update, but not worried about that. Will PR in jumpy soon.

Trying to add some project setup docs to call out this issue:
fishfolk/fishfolk.org#21

Otherwise, I think can close this, no change needed in bones.