-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Salesforce CLI Local Git Repository Corruption #2483
Comments
Hello @bjconover 👋 It looks like you didn't include the full Salesforce CLI version information in your issue. A few more things to check:
Thank you! |
Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support. |
{ |
@bjconover does this occur every time that you rename or create a file? Have you noticed if it's a specific metadata type that triggers the issue? If you're able to provide replication steps that would be a huge help. Thanks! |
Hello @bjconover 👋 None of the versions of Shared: Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. After updating, share the full output of |
FWIW, I have been seeing this occur more and more frequently over the past few weeks. I have other developers seeing the same thing. Deleting the source tracking folder does help sometimes. |
If you just rename the index file in the local source tracking that will fix the issue too. The system will generate a new index file and that will let you start making deployments again. |
The problem is intermittent, but I've had it happen on several occasions right after I renamed a LWC. But I've also had it happen when I make a code change and go to deploy it. I mentioned that I was having this issue to one of the consultants that was manning the Salesforce CLI station at Dreamforce 2023 on Tuesday, and he said he ran into the same issue and was able to fix it by deleting the index file. This is the fifth or six time this has happened to me over the past couple of CLI versions. Here are a couple of other related errors I have gotten: I've also seen it mention that the magic number is invalid. (Invalid dircache magic file number) |
This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted. |
We believe that this issue has been resolved. Please make sure you are using the latest version of |
I was getting the following error all the time when trying to "SFDX: Deploy This Source to Org" or "SFDX: Retrieve This Source from Org":
After deleting the file suggested by the OP, the commands started working again. Is the error back? |
Hello @bjconover 👋 None of the versions of Shared: Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. After updating, share the full output of |
I am facing similar issue when trying to retrieve the metadata using package.xml (using right click retrieve metadata from org option) even after updating the SF CLI to latest version i.e. 2.60 Error details: Metadata API request failed: An internal error caused this command to fail. isomorphic-git error: here is the details of the "sf version --verbose --json" what should be done to resolve this issue? |
Hello @bjconover 👋 None of the versions of Shared: Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. After updating, share the full output of |
This has been an issue for the past couple of Salesforce CLI updates, but occasionally when you go to deploy an update to your org you will receive the following error or something similar:
An internal error caused this command to fail. Please file a bug report at https://github.com/isomorphic-git/isomorphic-git/issues with this error message: Invalid checksum in GitIndex buffer: expected 746e672f6173736574732f69636f6e732f737461 but saw 83e736f3a0e62161efb4e92134ffe7e8e7cafa9e
I found that when you rename a file or create a new file it can cause this system to get into this state.
To fix the issue, you need to go to the .sf\orgs(Org Id)\localSourceTracking directory and delete the index file that is populated. Once that is done when you deploy\retrieve files again the index file will be regenerated and the issue will be resolved.
I have fixed this issue several times, but it keeps popping back up again from time to time and I have to repeat the steps I listed up above to fix it.
The text was updated successfully, but these errors were encountered: