Pub 2.8.1Windows 10 1909 build 18363.418Pub get is not aware of platform specific EOL conventions which makes git go crazy and report changes to pubspec.lock even when the packages are still the same.
To reproduce:
flutter create buggy)cd ./buggy & git init)git config core.autocrlf true)git add . & git commit -m "Initial commit")pub getThen if you do git status a change to pubspec.lock is reported even if the content is the same (except the EOLs)
pub get should use CRLF as a EOL character when on windows.
pub get writes pubspec.lock file with LF characters.
Thanks for reporting.
You can configure git to use LF for specific files (for example pubspec.lock).
See eg. https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings
Most windows tools today work fine with LF endings. I am not sure we are going to change this.
@jonasfj WDYT?
We could mention the .gitattribute fix on:
https://dart.dev/tools/pub/troubleshoot
Hmm, but if this is a problem for many users we should come up with a solution. I don't actually know if windows users generally use CRLF or just LF. We should probably find out what most Windows users do, if they have git config core.autocrlf enabled or not.
But a possible solution would be read the existing pubspec.lock file and if it is valid YAML and uses CRLF then we write the new pubspec.lock using CRLF.
I'm not sure why git think there is a change, if it tries to make a commit, then after converting back to LF there should be no changes.
I wonder what other package managers do?
https://github.com/npm/npm/issues/17161 npm had the same issue.
They did detection of current newlines: https://github.com/npm/npm/pull/18943. (Well actually https://github.com/npm/npm/pull/19904 but it seems they would have preferred the other).
Detecting newline-mode is probably rather harmless... As a linux user I can't imagine having CRLF anywhere. But if somehow I got CRLF in my repository, there is supposedly no harm in preserving it when updating pubspec.lock.
Another possible fix is to do a deep-compare of YAML dictionary from pubspec.lock with the dictionary we want to write. And if there is no change we don't overwrite the file and instead just touch it (to update timestamps).
I guess we don't want to preserve newline style in .packages and .dart_tools/package_config?
These are not supposed to be checked in, and should thus not give problems with source control.
I agree, that for .packages and .dart_tool/package_config.json we don't do anything they should never be checked into git anyway.s, or copied between computers..
We could use the platforms preferred newline format if we wanted to.
We could use the platforms preferred newline format if we wanted to.
We could... But besides that being more complicated, I am not sure that \r\n is always the preferred line-ending on windows. I think that depends a lot on the tools you are using.