Use .gitattributes to remove user configuration influence #28945
Conversation
| *.jxs eol=crlf | ||
|
|
||
| # Some scripts require specific endings, others use specific in vscode | ||
| *.bat eol=lf |
There was a problem hiding this comment.
📝 Normally this would use eol=crlf, but the repository is not currently following this convention.
| # Some scripts require specific endings, others use specific in vscode | ||
| *.bat eol=lf | ||
| *.cmd eol=crlf | ||
| *.ps1 eol=lf |
There was a problem hiding this comment.
📝 Normally this would use eol=crlf, but the repository is not currently following this convention.
| @@ -0,0 +1,149 @@ | |||
| # Auto-detect text files | |||
| * text=auto | |||
There was a problem hiding this comment.
📝 If the repository requires the use of a specific line ending by all users, it can be added to this line, and we can remove everything below except the exceptions to this case. However, the preferable case is to not require a specific line ending and instead allow it to be controlled by the user (or automated system) which checks out the code. For example, a build machine which validates line endings (I believe this is "hygiene" or something), could use the following configuration without being a noisy neighbor to all other contributors:
git config core.eol lf
|
@sharwell How did you normalize all line endings? I can't find any difference between |
The .gitattributes file tells git to store files as text instead of storing files as binary. In a way, you can consider a "line ending" in such a file to be a opaque sentinel - it has some representation in the Git database but when you view the blob or check out the commit to files on disk it will be written to either LF or CRLF according to the current platform and configuration in .gitattributes. For the cases where a file appears to have changed in source control due to this PR, it's almost always due to a conversion of LF and/or CRLF to this sentinel.
In the past, you could do the following: However, this no longer works as one would expect. I now use the following process to normalize files:
I then manually review the result to correct any unwanted changes. For this repository, it mostly meant setting the execute bit back on some files that changed. I watch for other "bad things" as well, such as the unintentional renaming of files in source control due to differences caused by file system case sensitivity. After the above process was complete, I made a second clone of the repository. With |
|
Wow. I know our hygiene scripts aren't exactly state of the art, but they get the job done. How is this exactly going to benefit us in the future? Did you happen to come across a situation in which you had the wrong line endings? Also, can you resolve the conflicts? |
Users will no longer need to configure their repositories locally for development. Regardless of configuration or platform, the submitted results will end up as a NOP for hygiene.
Yes, my system is configured for
Yes, I'll get it in later today hopefully. I'll do another verification pass to ensure everything is still consistent. |
|
Will close this for now. Too many conflicts to deal with. Will re-examine this in the future. Sorry @sharwell |
This change eliminates the influence of the core.autocrlf setting on local checkouts. While it looks like a substantial change, users should see binary identical content of the entire workspace, with the exception of the .gitattributes file, before (for core.autocrlf=input) and after (for any setting) this change.
💡 It is highly preferable to remove as many
eol=crlfandeol=lflines from the current .gitignore as we are able to. For each such case, Windows users will see the file locally with CRLF line endings and other users will see the file locally with LF line endings, but neither system will ever influence the other. For any case where use of a specific line ending is not required for proper behavior, we can allow this platform-specific use without negative consequences.