All Collections
Comparisons and deployments
In git with org comparisons, why are the results different from org to org comparisons?
In git with org comparisons, why are the results different from org to org comparisons?
Valerio Chang avatar
Written by Valerio Chang
Updated over a week ago

In Gearset, the processes to compare

  • org to org

  • git to org

  • 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.

Managed package items

If you have the Include managed packages set to None this will

  • retrieve no managed packages from an org

  • possibly retrieve managed package metadata from git, depending on whether the Installed package metadata type is included

As the Git API does not have the concept of managed packages, the original behavior was that this setting did not affect retrieval from git. However, Gearset has since added filtering to remove namespaced items from the git side if Include managed packages is set to None.

We apply this filtering by checking the Installed packages to get the names of all the managed packages. Then we can use that information to filter out the managed package metadata from the git side of the retrieve. This means the Installed package needs to be present in the branch and included in the comparison for the managed package metadata to be hidden.

If not, having the managed package metadata show up on the git side can result in permissions showing up as New or Deleted. The easiest way is to spot this is the namespace prefix in the item name; for example dsfs__ in the following screenshot.

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, 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 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?