Gearset uses the Salesforce metadata API to deploy the metadata to the target. The API has a lot of quirks where there are some metadata that it can add but not remove. Here is a list of the ones we have come across:
The API can add and change Lightning page assignments, but not remove lightning page assignments. These show up as
<profileActionOverrides>in the XML.
The API cannot delete a Flexipage AppActionOverride set to App Default. It's suggested to instead remove the override using the page assignment wizard in the Lightning App Builder UI.
The API cannot delete picklist values, they just become inactive.
The API can add custom metadata type access to profiles, but not remove them.
The API can add and change field dependencies, but not remove field dependencies if it would leave the dependent field value with no dependency to a controlling field value. This shows up as
<controllingField>in the XML.
The API can edit profile login IP ranges, but not delete them.
The API can and and edit
Skillmetadata types, but not delete them.
The API can edit profile
<description>fields, but not delete them. For example, it's possible to change the userLicense in the following deployment, but the description will not be removed.
The API can add existing custom permissions to profiles, but not delete them.
The API can add existing
<translation>to custom object translation, but not delete them.
The API cannot delete Custom application translations or Custom label translations
The API can add or change record types, but cannot delete them (this also applies to
record type visibility). There is a Gearset problem analyser that suggests removing record type deletions from your deployment. If you ignore it and try to delete a record type, you will get the Salesforce error
Cannot delete record type through API.
This behavior can be confirmed by testing via Workbench, another tool that uses the API. Other users who come across this problem have been executing these destructive changes manually.
If in the future Salesforce do add support for these via the metadata API, then we would be able to support these destructive changes, however currently we are limited by this API restriction.
Additionally, we found that the API cannot deploy