Even though this example has an easy workaround, it does seem like a scenario which could present issues in other deployments.

In the scenario where a standard application that doesn't exist in the target (ex. Sandboxes and LightningInstrumentation) is included in a deployment (along with its permissions), there's 2 problem analyzers that come into play

1. "Remove standard application additions/deletions from deployment"

2. "Remove items which reference the listed components which are not available in the target"

When both metadata types are selected (application and permission) only #1 is flagged. This means Gearset removes the standardApplication, but leaves the references to the application in the profile which causes the deployment to fail.

In retrospect, the changes made by analyzer #1 should either cause #2 to flag it or #2 should flag it in general since the application doesn't exist in the target.

The workaround is to make sure your CI jobs or deployments to sandboxes to do not include standard apps that don't exist in Salesforce. However, this puts the work/onus on the end user whereas the analyzer already exists to solve this for us.

Sometimes, the "Next" button on the comparison page does not work. In the Developer Console I can see a 403 response from "POST https://app.gearset.com/api/static-code-analysis", traced to "raygun.js:2016".

In this case, I have to reload the comparison page.

This happens quite often (I estimate 1 in 5 times).

I don't think that it's a timeout issue (CSRF token or sth.), because just right now I only marked one file in the comparison list and wanted to proceed, and the button didn't work.

On other occasions, I spend a lot more minutes on the comparison page, and the button works perfectly.

This bug happens to other collegues as well and is a "known issue" amongst our Gearset users.

My browser is Google Chrome 83.0.4103.61 on a Ubuntu 18.04.4 LTS.

I believe this to be a bug, but it might be intentional. In any case, the current functionality is, in my opinion, poorly conceived.

If a user adds a deletion to a comparison between an org and git, the deleted metadata is the only item that will show up in Gearset. However, if you inspect the resulting commit in git, you will see that the metadata was deleted along with all of the profiles, layouts, etc that had to be changed as a side effect.

I'm completely fine with Gearset detecting these dependencies and making the changes to them. It makes sense!

I'm NOT fine with Gearset never actually showing me the list of changed items due to these side effects.

Thus, my suggestion is for Gearset to always include the full list of changed metadata that will be pushed to the target org/source control. Even if that type of metadata is not a part of the original filter.

For reference, here is an example that a Gearset employee was able to produce.

Apex class deletion in Gearset:
https://gearset-b442bc7f2cf1.intercom-mail.com/i/o/141563438/5255f13a74f6114073275083/File1565950331859

And the resulting commit over in github:
https://gearset-b442bc7f2cf1.intercom-mail.com/i/o/141564016/2f209aca43e7a48b6d492285/File1565950510246

I believe that Gearset should show the same list of changed files that end up being pushed into Github.

When viewing old/past deployment details, that old deployment shows me the big blue banner saying that ---this--- was our {insert total number of deployments ever}th deployment no matter which old deployment I'm viewing.

This confused me a bit because I wanted to view our say 5th deployment ever so expected the number to say this was our 5th deployment, and I ended up closing the details browser tab twice thinking I pressed the wrong button to view the latest deployment. Yeah I could have looked at the tiny timestamp somewhere on that details view, but this large blue banner/counter just keeps tricking my brain into thinking I messed up :D

In Deployment history, there are two buttons I use the "view details" which I can open in a new tab without leaving the list of deployments, and the "clone package" which I can't open in a new tab. I can workaround it easily (duplicate tabs, or first view details then clone from there), but it was disappointing that I have to.

I needed to re-deploy say 10 deployments into a different sandbox and so the clone package feature was amazingly useful, but this little nag prevented me from entering the blissful nirvana of wielding the perfect tool for the job at hand.

The comparison view contains a list view in a scrollable area with an line item for every metadata item in the comparison. Depending on the comparison, this list can be exorbitantly long (10k+ lines). Displaying this many elements on screen is extremely inefficient, and causes browsers to lock up when selecting the "check all" check box (because it results in thousands of incremental manipulations in the DOM). This issue also causes mobile browsers to crash when more than a thousand or so items show in the comparison results.

There is a common pattern for handling long lists like this, in which a finite number of list items exist in the DOM. These list items are reused as a user scrolls through the list. Once a list item has scrolled far enough out of view, it is moved to the opposite side of the list, and its content dynamically updated to display the appropriate data for that index.