When I run sf project deploy preview it shows particular files as conflicted. However, when I run SFDX: Diff File Against Org, it shows as identical.

What does it mean to have a conflict when attempting to deploy? And how does one resolve it?

enter image description here

  • Why the downvote? If there is a conflict, then why is there no difference between the files? Am I missing something? Or is the CLI tool not working properly?
    – Z0q
    Commented Jan 29 at 18:50
  • 4
    There's always that one person who tends to downvote everything (without explanation). Maybe they thought you didn't include enough detail or research? Who knows? At any rate, you may want to look over the sf project reset tracking documentation to see if that may be appropriate.
    – Derek F
    Commented Jan 29 at 19:09
  • @DerekF Thank you, though please note: Use with extreme caution. on the first line :)
    – Z0q
    Commented Jan 29 at 19:43

1 Answer 1


Source tracking works by grabbing the last modified time stamp from the file when you do a pull or push, and also tracks the timestamps of the local files. If the last known time stamp on the server is different, then we know the server copy has been modified. Similarly, if the local time stamp has been updated, both sf and git will observe that the timestamps don't match, and show differences, even if there are no actual changes to the file. If both timestamps are modified from their original values, we have a conflict.

It's a really simple algorithm, which is why it doesn't take long to figure out if there's a conflict. However, this also means that it's not terribly accurate, because just doing something like touch force-app/default/main/classes/Utils.cls will make sf think the file's been modified (touch is a utility that updates the timestamp without modifying a file).` Similarly, using something like VS Code, simply pressing Ctrl+S to save a file triggers the file save handlers, such as automatically formatting the document.

In summary, simply changing the file's last modified timestamp locally and making a trivial edit on the server is enough to cause a conflict warning. Also, note that if you use the deploy method instead of push, or if you're working in multiple directories that point to the same org, etc, you can trigger a conflict warning without any actual content change. As you've noted, "use with extreme caution" is warranted. This answer is more an explanation as to why and how such events can occur.

  • Thank you. I guess that answers my question. But how do I do a full deploy and not deploy conflicted files? There is an --ignore-conflicts flag, but it doesn't ignore, it actually forces them to deploy
    – Z0q
    Commented Jan 30 at 10:43
  • I retrieved all files that I didn't want to deploy from the org, to leave them unchanged. I guess this algorithm doesn't work that way?
    – Z0q
    Commented Jan 30 at 10:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .