It would be incredibly helpful to trigger Gearset comparisons, validations, deployments, etc. from an external source using an API. Our team uses GitHub for our VCS, which provides the perfect opportunity to:
1. design webhooks to validate changes in order to approve a Pull Request
2. design webhooks to automatically deploy changes to an org once the PR is approved.

Additionally, CI tools such as Jenkins, TravisCI, TeamCity, etc could use such an API to design complex builds that still employ Gearset, but use the external tool for additional actions outside of what Gearset provides for their CI features.

It would be great to have more control over the diff process - particularly to be able to ignore whitespace changes.

If I've made an actual function change to a class, and also auto-indented it, then it would be a lot easier to see the important change if I could hide the whitespace-only changes.

Having the ability to suppress whitespace-only changes on the list of changed objects would be really useful, too.

As Gearset is run through a web browser, if the browser happens to freeze while a package is being built, you don't have the opportunity to save it as a Draft Deployment. An auto-save feature would allow someone to pick up where they left off, or when the last auto-save was done, without having to start from scratch.

Extend the diff tool to allow the user to perform a merge, creating a new version of the component that contains some changes from the source version and some changes from the target version. This would be very useful in a team development scenario where multiple devs are working on features in individual dev sandboxes and then pushing completed features into an integration sandbox.

Running tests displays overall org code coverage... it would be cool if you could provide individual class code coverage statistics as well, so we could get a good idea of what classes / triggers need attention

I'd like to be able to name 'Pairs' of orgs so I don't have to re-select them, like 'DEV to UAT' or 'HOTFIX to Production'

Enterprise Users can only "Run Now" Jobs that they own. If the Source and Destination Org are shared, allow other enterprise users to run the job.

With Gearset's current the ability to associate a deployment with Jira tickets, and post updates as comments to the stages of deployments, the ability to choose the status (from what is defined in the status of the Jira Board), upon a SUCCESSFUL deployment, would be incredibly helpful in our environment plans for our projects.

By being able to select the status to update all tickets to from the Jira board, we could effectively manage our custom stages for different projects.

It would be nice to be able to deploy to multiple environments all at once from one source.

Allow assets with "no difference" to be added to a promotion to allow the same package to be used to both promote as well as sync other sandboxes (without having to manually check if asset was changed in each).

I have certain metadata which is broken or dangerous to migrate from a dev org, I'd like to exclude it from this and subsequent releases. If I could 'right click' and ignore it that would be good.

In order to support a development pipeline (e.g. Dev Environment -> Staging Environment -> Production) allow Metadata from the source Org to be modified before deployment to the target Org.

e.g. I have a RemoteSiteSetting in source that points at https://dev.example.com and in my staging environment I need this to point to https://stg.example.com

When comparing flows (processes) between environments, Gearset appears to try to match on flow version number, even though different environments are likely to have different numbers. It seems like it would probably be more helpful if the comparisons were between just the active versions.

Being able to configure which problem analyser results to use in CI jobs.

For instance, we can’t deploy any changes to managed packages because the problem analyser will ignore them (even though we have components from a managed package that we can modify and deploy without issues), that would help to reduce our manual steps during deployments.

ANT is unable to change the type on an EmailTemplate from HTML to CUSTOM. To solve that we need to add the EmailTemplate first to the destructive package to have it removed and then add it again with the package.xml
Since this file is not deleted but just changed. It doesn't show up in the deleted items tab.

We should add an option to the "Selected Items"/"Changed Items" list to opt-in for adding that to the destructive.

For example; when adding new custom fields, you generally have to add the permissions as an additional line item to the deployment. Having a checkbox or something that will have gearset automatically add the permissions associated with the metadata currently in the deployment list would speed up the process. Users should also be allowed to deselect lines that were automatically added.