In Gearset, the processes to compare

  • org to org,

  • git to org, and 

  • org to git 

are identical, so it's super easy for users to start comparing metadata in source control. However, there are some nuances and restrictions.

This is because the retrieval calls to orgs and to git use fundamentally different APIs, which can result in the following differences when compared with an org to org comparison.

List of named items

The list of Named items is populated from the list metadata call in the Metadata API. This call is not possible with git branches; therefore, you will only see named items from an org (regardless of if it's the source or target of the comparison).

If your new item is in the git source branch, to retrieve it in the comparison results, you will either need to use All items, or have it set to Named items but use the 'include all' regex .*. The advantage of .* to include is that you can use it in combination with exclude rules, if you don't want to include everything. For more information on using regex in custom metadata filters, please follow this link.

Alternatively, you can also specify the new item by its API name. Type the name into the box shown below, and click Add. If you misspell the name, then nothing will be retrieved.

Managed package items

Additionally, if you have the Include managed packages set to None this will

  • retrieve no managed packages from an org

  • retrieve metadata regardless if they are from a managed package or not as the Git API does not have this concept of managed packages

This can results in permissions showing up as New or Deleted. The easiest way is to spot the namespace prefix in the item name. For example dsfs__ in the following screen shot.

Profiles, permissions and other junction objects

As documented in this article, we know that profiles and permissions can show up differently in orgs compared to git. This behavior extends to other junction objects.

For example, to return a Profile:

  • in an org, you must include the Profile and the Custom object metadata types;

  • from git, you only need the Profile metadata type

For Profile: Application visibility items to show in the comparison:

  • in an org, you must include the Profile and the Custom application metadata types;

  • from git, you only need the Profile metadata type

This can lead to items appearing to be different in git compared to the org, or present in git but not the org, when in fact if you add another metadata type to your filter, the the items will show as the same in git and the org.

For more information on metadata types required to retrieve different Profile subcomponents, please follow this link.

If there are other things that don't look right, please get in touch with us on the in-app chat!

Did this answer your question?