Properly handle line endings #756
Conversation
|
the intent of the .gitattributes previously was to ensure that *.sh files do not ever use crlf line endings locally. It seems in quick review that this is no longer the case? |
|
On Mac OSX or Linux nothing will use CRLF locally. Everything is normalized to LF within the repository and will be left that way. On Windows, the conversion to CRLF will occur locally when reading from the object database. Not sure that would be an issue, since we certainly aren't executing any BASH scripts on Windows... right? Take a look at the links I added to the ticket (referenced from the PR). I'm pretty confident what I've committed here is in line with best practice. |
|
I intentionally ignore CRLF conversion for *.sh files because I think it is nice to ensure bash scripts stay correctly formatted. You can then run them in cygwin without having to manually convert and in particular because we do a lot with EMR, we don't have to manually convert them before putting them on S3 or scp'ing to a cluster. Its just an additional thing those working in windows environments have to be careful about when it seems unnecessary? For example, everytime you change branches git will change the line endings back to CRLF without it explicitly set in the .gitattributes and if you are using these scripts you have to then make sure you constantly manually change the line endings. For other files, like source code files you'd typically want this behavior, but for *.sh I can't really think of a reason you'd want CRLF even in Windows. |
|
Fair enough. I'll push another commit to leave the .sh handling as it was previously. |
See details and links on issue #755