5

When working with sfdx force:source:status the documentation cites as exemplary result:

STATE                     FULL NAME      TYPE         PROJECT PATH
Local  Deleted            MyClass    ApexClass    /MyClass.cls-meta.xml
Local  Deleted            MyClass    ApexClass    /MyClass.cls
Local  Add                OtherClass     ApexClass    /OtherClass.cls-meta.xml
Local  Add                OtherClass     ApexClass    /OtherClass.cls
Local  Add                Event          QuickAction  /Event.quickAction-meta.xml
Remote Deleted            MyWidgetClass  ApexClass    /MyWidgetClass.cls-meta.xml
Remote Deleted            MyWidgetClass  ApexClass    /MyWidgetClass.cls
Remote Changed (Conflict) NewClass       ApexClass    /NewClass.cls-meta.xml
Remote Changed (Conflict) NewClass       ApexClass    /NewClass.cls

On conflicts, the docs say

Notice that you have a conflict. [...] In this new development paradigm, the local project is the source of truth. Consider if it makes sense to overwrite the conflict in the scratch org.

In addition to that approach, I want to learn how to efficiently diff local vs. remote conflicts in Salesforce DX.

2

As far as I understand, when Salesforce released SFDX they did it to provide a way for developers to easily integrate a Version Control System (VCS) in their development cycle, as well as many other reasons.

Therefore, if you're developing using SFDX, it would make much more sense to integrate it with Git, Mercury, TFS or whichever VCS you prefer and directly diff the branches, not local code vs org code.

One of the best advantages of SFDX is that you no longer have the organization as the source of truth but the actual VCS repository - that's why Salesforce recommends overwriting whatever is in the org always. It's a bad practice to toggle the source of truth from VCS to org and back.

Now, regarding the diffing, in git, to diff local branch to remote, it's as easy as executing git diff <masterbranch_path> <remotebranch_path> or simply use a visual tool like Sourcetree.


EDIT - Comparing a previous commit with server code

So, let's say you've made three commits in local and pushed them to remote (A, B and C in this order) but you want to compare commit B with whatever you have in the server (Salesforce Org) to see what has changed. In that case the best approach imo would be to retrieve your SF metadata to local and then diff with that commit with the git diff command, or a visual tool if you prefer. The command would look like:

git diff a772eb592db224f4b8688d629223f9d16739bebf

Being that long string the revision number/hash of the commit.

As I've already said... got for visual tools since you can do it with a couple of clicks without having to copy-paste large strings like the latter.

The main advantage of going for this approach vs the typical local/server diff we're used to is that we have every single change ever done to our code tracked by git, allowing us to perform very powerful diffs as well as reverts, etc.

BTW, take into account that whenever you pull your code from your Salesforce instance to local you will be overwritting everything, so if you have uncommitted work, you might want to at least stash it before retrieving in order to not loose work.

I hope this answers your question :)

| improve this answer | |
  • I was not referring to local vs remote in the git sense. I want to diff my local dx code with the code in my scratch org - apparently something changed, and I want to find out what exactly. – Christian Szandor Knapp Nov 16 '17 at 11:53
  • 1
    Would it make sense then to pull stuff from the org to local (overwritting) and diff local with remote? That way you can use the git diff tools and once you find your differences, get your code from the vcs again. – Javier García Manzano Nov 16 '17 at 12:09
  • If u post this as an answer (edit yours), I'll accept it with one caveat: what if both files have changed? Locally committed and on the DX org changed, too. Seems to me I'd have to diff the previous git commit not the current state of my local code – Christian Szandor Knapp Nov 16 '17 at 17:16
  • Well, in case you want to compare with a previous commit, then you can directly compare with that commit with the git diff. I'll elaborate in my answer :) – Javier García Manzano Nov 20 '17 at 10:39
  • There - I tried to be as clear as possible. If you have further questions, don't hesistate to ask so I can also further clarify and see if it makes sense! – Javier García Manzano Nov 20 '17 at 10:57
0

The easiest way I found is to rename your local file with .old suffix, for example, and then do a pull with --forceoverwrite flag to download the new version from the scratch org. then you can compare your .old and new files locally and choose which one to keep. Hope this helps.

Edit: SFDX actually does the same when you try to convert metadata API format to DX project metadata format and there is a conflict, but instead of using.old, it will append .dup to the new file version.

| improve this answer | |
  • Rename sounds excessive. Wouldn't it make more sense to create a new branch, pull, then diff the branches? – dzh Nov 17 '17 at 6:51
  • Well of course you could compare using the diff of your VCS, but imagine you already are working on a feature branch. Scenario: You have a master branch for your DX project. You want to develop a new feature, so you checkout a branch called newFeature, you start working on it. Now you push newFeature to your new scratch org you created. You go to scratch org, make some changes. You also make some changes in your editor in newBranch. Now you have a conflict. Would you create another branch just to compare? – Andrej Lucansky Nov 17 '17 at 8:59
  • What you could do is to commit your local changes to VCS and then pull from scratch org with -f flag and diff your new pulled stuff from scratch with your latest commit, but probably you don't want to commit something just so you can compare, you want to commit the merge of changes in your local and the changes in the scratch, right? To merge that properly without polluting your branch, you need both files in local to merge, and for that you don't use VCS, but a diff function of your IDE. Therefore, renaming of file, so you don't overwrite your local changes. – Andrej Lucansky Nov 17 '17 at 9:01
  • Of course, you can also create another branch and pull and compare branches, then delete the branch, but I find it quicker to press F2 and rename file, pull, merge with IDE diff. – Andrej Lucansky Nov 17 '17 at 9:05
  • Fair enough, that sort of makes sense, but which file are you renaming? The main folder? – dzh Nov 17 '17 at 9:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.