If there are multiple users making changing the metadata in Salesforce and when one has to deploy their changes, it is not possible to pick the changes that are specific to one person, For this we have to go to VS code and use git patch mode to add only the necessary changes for a specific user. If we have an option to edit the xml after the comparision and pick only necessary pieces and deploy it to next org will save time and also switching between multiple orgs. Currently the comparison editor is read only mode.

Deploy first fields where <trackHistory> was changed from true to false.
I am currently deploying fields changes and getting error that too many fields are tracked because fields with true ale deployed first.

This is a common issue with deploys from VCS to orgs and especially so for standard objects when SFDC introduces new versions and hence new objects

Example: In V53, SFDC introduced Standard Object "Customer"

If your VCS doesn't have a CustomObject for Customer and a Layout for Customer, the CI job will attempt to delete the Layout and get an error - you can't delete the only layout"

The Analyzer should detect this with recommendation to not delete; then CI jobs can honor this and not fail

When deploying a branch to a Salesforce org where there is a managed package version mismatch in the file metadata, it would be nice to be able to bypass this discrepancy as there are occasions where there may be a newer package version in a lower/sandbox org and an older package version in a higher/production org.

If you compare Custom Fields and try to deploy something in an Object that is in a Master/Detail relationship without including the Lookup field, Gearset will warn you that the deployment will fail.

However, if you don't include "Custom Fields" in the comparison, (for example just comparing Validations) and try to push it, you will hit an error:

"Cannot set sharingModel to ControlledByParent on a CustomObject without a MasterDetail relationship field"

Gearset could easily warn the user on this when trying to push a Validation Rule on a MasterDetail object, even if Custom Field was not added to the comparison.

When you delete a custom object, the Repo Cleaner should remove the references to that custom object in the Settings metadata type - specifically SearchSettings | <searchSettingsByObject>

Otherwise, it becomes impossible to deploy Search Settings via CI jobs

when Gearset Analyzer tells you that you should consider removing a permission from the deployment, it displays the API name of the permission but often this doesn't tell you what item in the Setup UX you need to check on

example:

ContentHubUser is actually the permission for Files Connect Cloud My suggestion is that Gearset take advantage of this resource http://www.fishofprey.com/2020/10/mappings-between-salesforce-permission.html and display both the API name and the UX name in parens - such as :
ContentHubUser (Files Connect Cloud)

Currently, attempting to deploy a named credential will fail as a "password is required for the specified authentication protocol".

This can mean manual work if you have a lot of CI deployment jobs to sandboxes or annoyance if you expected to be able to deploy it.

It'd be great if an analyzer existed that would alert/warn the user about it going to fail and unable to be deployed (suggest removing it from the package)

In a CI job : Validation shown as success & Deployment shown as success. But actually no workflow deployed due to it being removed in the Problem Analyser.

The Problem Analyser triggered due to the (standard) object, that the workflow depends on, not being in the comparison results.

In a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap - problem analysers should never fire on object dependency.

CI job : Validation shown as success & Deployment shown as success.. but actually no WF deployed. Saying Opportunity object doesn't exist in target just because it was not selected in the components. in a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap.

Ensure that Apex Classes imported in LWC javascript files are included in dependencies.

In order to make deployments more repeatable between orgs please allow a way to save the selection of deployment analysis suggestions an d list of test classes with a package. With a large package it can be difficult having to document or remember the same selections used in deployment to UAT org for Production deployment.

The dependency crawler that GearSet offers is one of its biggest strengths. A lot of manual labor can vanish at the click of the button. Best example would be the addition of all relevant Picklist fields when a Record Type is added to the Selected Items.

Sometimes deployments still fail, and in particularly big orgs the dependency crawl takes ages, each time I have to rerun the problem analysis.

A way to add the metadata that was auto-added prior to the deployment to the list of Selected Items to make future analysis faster would be greatly appreciated.