When I choose to compare metadata with my source as my VCS, there was an "&" char in the recordtype XML definition file.

    <values>

        <fullName>Food & Beverage</fullName>

        <default>false</default>

    </values>

This threw an error and there was no support and no explanation at that time.

I suggest you to improve this error message.
Message I got:

Could not parse the XML for 'force-app/main/default/objects/Lead/businessProcesses/Buyer.recordType-meta.xml'. Error occurred at line 71. Further details: An error occurred while parsing EntityName. Line 71, position 29.

File, line and position it's ok. maybe a link to Gearset docs with walkthrough with this probable cause when a parsing error happens.

Gearset offers various automated jobs that run overnight e.g. Org Monitoring Snapshots, CI Jobs, Unit Test Runs.

it would be great to be able to set an ordering on how those run for any particular org. For example, a natural order for the night jobs may be:

1. Monitoring Snapshot


2. CI run


3. Unit testing

This means we have a backup before making any potential CI changes and the unit tests show the results after CI. It would also allow us to make sure that the jobs don't clash.

Ideally, we'd be able to do this without just specifying exact times to start each job because the length of time per job may change over time. I'd like to be able to just set the order, and maybe a start time for the whole sequence.

When attempting to validate a deployment, and the validation fails, Gearset retains the deployment's friendly name and notes fields from the validation. The user can make any necessary changes to the deployment, and won't have to re-type this information when attempting it a second or third time.

I'd like to see this same functionality when dealing with a failed deployment that doesn't use validation. Validating a package takes two steps (long steps), and typically I only want to use this option when delaying a deployment. However I often use it anyway just so I can retain my data in these two fields. It would save time to have the system remember the information for you.

We have a large org and need to select many filters. A comparison take ages. Source of our deployments is mostly Git, which is very fast in retrieving metadata. I would like to have an option, to assume that nothing has changed in target and skip loading metadata of that org and use the metadata of an earlier comparison.
If we have a small bug in our Git (e.g, test class not correct), we get an error while deployment. That's okay. We fix it in about 1min and want to deploy again. Loading metadata from Git is instant finished loading the metadata from the org need about 20-30 minutes. And we can guarantee, that nothing has change in the target. It is very annoying to wait so long, for just a little thing.

Gearset allows the selection of multiple External ID's in an Upsert operation as part of a Data Deployment.

However, the system implements an 'AND' combination across all the external ID's specified on the object.
Effectively, ALL external ID's need to be present on the target side for the match to be identified and record upserted. If all external ID's are not present, the system performs an Insert on the target org.

Please allow an 'OR' combination across multiple External ID's. Arguably, this should be the default option, but at the very least, a user needs the ability to decide how they want multiple external ID's to be interpreted.

User email are masked in Sandboxes and we can mask Contact emails as part of the data deployment. This still leaves the Org Wide addresses as valid emails. If there is automation that is generating emails related to the data that is loaded, they will be delivered to the Org Wide Addresses.

It would be useful if the same script that is deactivating validation rules could set email deliverability to systems emails at the same time.

In the even that email deliverability was set to all emails in the Sandbox and not adjusted before the data deployment we would have an extra safety net to prevent emails from going out.

When you update the change monitor report metadata filters and include new metadata types, the next monitor report shows all the newly added metadata as "New Items" on the report. Although not a big deal it did cause an alarm for us not realizing it was due to the change we made prior. It would be a "nice to have" feature if either you don't include the newly added metadata types as "New Items" on the initial report or flag them and have a visible cue to indicate the items were a result of newly added metadata items on the report filter.