right now, when compare/deploying two branches, Gearset only fetches the new changes and creates a whole new separate commit to be pushed to the targeted branch. This causes the targeted branch to lose track of all previous commits from the source branch and when compared in git, it thinks that the targeted branch is still behind. It would be very useful, especially for admins, to be able to use merge compatibility if and only there is no conflict between the two branches.

When a CI job is configured to post to slack, and a job fails, it is very useful to see the message posted with information about what failed (error message, number of components that failed).

However, when a CI job succeeds, it only shows the counts of changed/new/deleted objects.

It would be very useful to have the option to list out what was deployed - this would make it easier for devs/qa users who monitor these slack notifications to understand which deployments are relevant to them at a glance.

There's already a way to set up an outgoing webhook after a successful CI job run.

It'd be nice to have a way for a CI job to have an incoming webhook from another service, such as ElectricFlow (a build platform).

One use case would be for CI deployments to be dependent on external validation services.

For example after Jira status "Deploy" is captured doing a comparison and deploying the changes will work.

I have automated test jobs post about failed tests to our Slack. I want the posted Slack message to include a direct (though maybe shortened) link to the "Test run details" so that when we see Gearset telling us about some tests starting to fail I would be one click away from seeing a view of failed tests the message is talking about.

Next/bigger step would be a way to shape the Slack messages ourselves. The most basic templating setup where I could write my own Slack message with some placeholders like {{instancename}} or {{failedtests_link}}..

When creating a scratch org, allow us to select/configure a sfdx-project.json. This will allow for more complicated sfdx project to be deployed, i.e. multiple project folders, namespaces, ... etc.

When configuring a CI job, we need an option to set a deployment to another sandboxe when the deployment or test classes run successfully in the current CI Job.
Ex: when a push to a branch on VCS triggers a CI job to deploy to a sandboxe like QA (with test classes run), we also have the possibility to set an auto deployment to staging sanboxe when the the job on QA passed successfully.

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.

Currently, metadata from Unlocked Packages show up when comparing against an org. This leads to duplication of metadata in source control repositories (correct DX package repository and incorrect monolithic, "happy-soup" repository).

Using the Package2Member Object (Tooling API), it is possible to deduce whether or not a metadata item is part of an unlocked package. Therefore, it should be possible to ignore some or all unlocked packages (or any Package2 package), in a similar fashion to the way Gearset filters allow inclusion or exclusion of managed packages.

Part of our release management policy is for all deployment to be associated with JIRA tasks. I noticed that when cloning individual deployment the association with JIRA tasks is retained. However, when combining multiple deployments, the relationship with JIRA is broken and as a result, we need to re-associate each JIRA task back to the combined deployment package.

When configuring a CI job, we need an option to set a deployment to another sandboxe when the deployment or test classes run successfully in the current CI Job.
Ex: when a push to a branch on VCS triggers a CI job to deploy to a sandboxe like QA (with test classes run), we also have the possibility to set an auto deployment to staging sanboxe when the the job on QA passed successfully.

Allow to add Custom fields to Source control without objects in Source control. As we don't want to update existing objects in org.

It would be extremely useful for the development team to see the last set of commits which were deployed via an automated job, so that if it breaks it is easier to tell what broke the build or if it is successful what the org has been updated with.

"[TicketID,...] some comment"

Would be important to be able to integrate Gearset with an existing CI Tool like Bamboo, Jankins. (e.g an Bamboo Action or a generic Rest API which can be used by Bamboo or other 3rd party apps)