Open DetachHead opened 2 years ago
who asked?
@well i did, @so
No description provided.
Are you proposing to use the core.autocrlf
and core.eol
git config settings to decide which line ending to use in the baseline.json file? Is this just for when creating a new baseline.json file, or also when making changes to an existing one (that already has line endings)?
Should it also use git attributes like text
, eol
, working-tree-encoding
to determine what line endings / encoding to use?
Are you proposing to use the
core.autocrlf
andcore.eol
git config settings to decide which line ending to use in the baseline.json file? Is this just for when creating a new baseline.json file, or also when making changes to an existing one (that already has line endings)?
ideally both. currently it changes the line endings of the existing file to crlf regardless of the git config or the existing baseline file's line endings.
i would suggest using the git config when initially creating the baseline file, then checking the line endings on the existing file when making changes to it. that way it doesn't have to rely on the .git
folder being available all the time
Should it also use git attributes like text, eol, working-tree-encoding to determine what line endings / encoding to use?
no idea, never used them
One use of git attributes is to specify that certain file/s have a different line ending.
poetry.lock text eol=lf
tells git that poetry.lock
file uses LF (unix style) line endings
Currently basedmypy uses the system line endings. This change will only be regarding detecting the existing line endings and using that instead.
It can be frustrating when you have a git configuration to use different line endings to you system default, and mypy write baseline with system line endings instead of git ones. This causes vscode to have an error popup saying that the line endings are incorrect. For this change we will attempt to detect the existing line endings in the baseline file and use that when re-writing.