Closed ntotten closed 2 years ago
@ntotten we think this has something to do with the convert. Would you please provide us with more details on the files you are trying to retrieve, the version of the CLI, and steps to reproduce.
That was me that has the issue. It seems to be any Field file that has a formula in it. The CLI was 44.18.0 I was doing a SFDX: Retrieve Source from Org to get my Sandbox metadata into Source Format. Please let me know what else you need to work out what's going on.
Hi @JodieM, thank you for providing the extra information. I have added this to our backlog of bugs to be fixed. If you are able would you please also provide an example of a field that you are trying to retrieve and the command as you wrote it?
I first retrieved the whole org then right clicked on the file and used the SFDX menu option in VSCode. I did so many retrieves and Git things during this period so I can't replicate exactly how this occurred. If I see it again I will let you know
I can confirm this issue. We have a repo initialized with files that had LF. Now with latest 7.78.1 when I retrieve LWC I am getting it without any changes but some files have CRLF and others LF. This mix cause GIT to show diffs. I haven't found any pattern why some files downloaded from org still have LF and other CRLF. System is Windows 10 20H2 version.
Please add sfdx configuration to set default line endings. Then I can set "force LF" and sfdx should convert this in background. Then Git won't show differences and problem will be soved.
Hello,
I can also confirm this issue. My Git repo is configured to use LF when checking out. When I retrieve source with a simple manifest, using VS Code "SFDX: Retrieve Source in Manifest from Org", lets say :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Opportunity</members>
<name>CustomObject</name>
</types>
<version>50.0</version>
</Package>
I retrive most source files with full LF eol, including those with formula inside. But some other source files have a mixed eol : CRLF for the formula part, and LF for the rest of the file, as shown in the following screen shot for a validation rule (but it also happens with any source file including a formula) :
Same thing happens when selecting this same file and choosing "SFDX: Retrieve Source from Org".
Hoping those informations are helpful. Also hoping that a fix will soon be released !
Thank you.
$ sfdx --version
sfdx-cli/7.80.0-b979aae708 win32-x64 node-v12.18.3
$ sfdx plugins --core
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.0 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.9.1 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.4.3 (core)
alias 1.1.3 (core)
analytics 1.12.1 (core)
auth 1.3.0 (core)
config 1.1.11 (core)
generator 1.1.3 (core)
salesforcedx 50.5.0 (core)
├─ custom-metadata 1.0.10 (core)
├─ schema 1.0.1 (core)
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core)
├─ salesforce-alm 50.5.0 (core)
├─ templates 50.1.0 (core)
└─ apex 0.1.2 (core)
sfdx-cli 7.80.0 (core)
I have the same problem, there are some workaround that I can use?
Have you tried adding a .gitattributes
file to the root of the repository setting text=auto
?
text=auto
the sfdx still show conflicts, but now when i choose to override conficts git doesn't show 4k of changes, thanks a lot!!!
I fiddled with this for a while today and was unable to reproduce this issue. It's possible that these line ending issues have been resolved with the adoption of plugin-source
(released in 7.112.0).
Regardless, a teammate that uses Windows says they have been able to remedy line ending issues by setting git config --global core.autocrlf true
(git docs)
If you are still seeing this issue with the latest CLI version, please provide a sample org repo and include step-by-step instructions for replicating. Thanks!
When doing a
source:retrieve
of files that are already local, git detects these files as changed on even when there is no change. This was reported on windows so I suspect it is something to do with line endings.