Paket referenced via dotnet.tools.json (v 7.2.1); same version spec in paket.dependencies
per what I believe to be common practice, I specify * text=auto in .gitattributes; 99% of files are thus LF endings
Description
The paket docs don't provide a pit of success for the combo of:
using git
being able to dotnet restore or dotnet build from a clean clone (or git clean -fdx)
NOT having to run dotnet paket restore (as dotnet restore seems to include it and Just Work as long a the Paket.restore.targets file is present)
Expected behavior
Never end up with line-ending only diffs in git
Never have to invoke paket restore
Actual behavior
If/when I edit/merge Paket.restore.targets, the line endings change to LF
If/when I paket install etc, the file is replaced with a CRLF-endings based file
If I don't commit `Paket.restore.targets, restore does not work without a paket restore
Desired behavior/crazy ideas
I'd be very happy to be told about the xyproblem.info nature of my reasoning and told a better solution, but I feel I've definitely done the legwork to try to figure this out!
I see the following potential general directions to resolve the issue:
Add a doc section that covers what to do (atm it has many generations of advice, but nothing that suggests that it's currently a good idea to add Paket.restore.targets to your repo). I would propose to add some version of the Known Workarounds below to the docs.
Tweak Paket's behavior in minor ways. e.g.
if it figured out the expected line endings and wrote paket.restore.targets per that ?
if paket autorestore printed a message recommending to commit the Paket.restore.targets ?
Do a more complete fix or V8, e.g.
Have a /paket.targets in base of repo (with line endings per .gitattributes)
Update the docs to say to commit /paket.*
Either have Paket autorestore put a CRLF override in the .gitattributes, or respect the repo's rules
I'd be prepared to do solution 1 if I get enough input
I am not sufficiently au fait with current gen paket to do solution 2
I don't realistically have bandwidth to contribute to the impl of solution 3, though I'll obviously test and type here.
Known workarounds
(Assuming typical gitattributes with typical * text=auto in effect)
Add .paket/Paket.restore.targets eol=crlf to .gitattributes
Add .paket/Paket.restore.targets to source control (with CRLF line endings)
Context
dotnet.tools.json(v 7.2.1); sameversionspec inpaket.dependencies* text=autoin.gitattributes; 99% of files are thus LF endingsDescription
The paket docs don't provide a pit of success for the combo of:
dotnet restoreordotnet buildfrom a clean clone (orgit clean -fdx)dotnet paket restore(asdotnet restoreseems to include it and Just Work as long a thePaket.restore.targetsfile is present)Expected behavior
paket restoreActual behavior
Paket.restore.targets, the line endings change to LFpaket installetc, the file is replaced with a CRLF-endings based fileDesired behavior/crazy ideas
I'd be very happy to be told about the xyproblem.info nature of my reasoning and told a better solution, but I feel I've definitely done the legwork to try to figure this out!
I see the following potential general directions to resolve the issue:
Paket.restore.targetsto your repo). I would propose to add some version of the Known Workarounds below to the docs.paket autorestoreprinted a message recommending to commit thePaket.restore.targets?/paket.targetsin base of repo (with line endings per.gitattributes)/paket.*I'd be prepared to do solution 1 if I get enough input
I am not sufficiently au fait with current gen paket to do solution 2
I don't realistically have bandwidth to contribute to the impl of solution 3, though I'll obviously test and type here.
Known workarounds
(Assuming typical
gitattributeswith typical* text=autoin effect).paket/Paket.restore.targets eol=crlfto.gitattributes.paket/Paket.restore.targetsto source control (with CRLF line endings)