Open chentsulin opened 6 months ago
Assigning to @getsentry/support for routing ⏲️
Routing to @getsentry/product-owners-issues for triage ⏲️
@chentsulin can you explain your workflow a bit more? The way we anticipate suspect commits to work is that a person creates a branch with commits, those commits get squashed into the main/master branch as a new commit, then the suspect commit finds that PR and the squashed commit. Is that not your workflow?
No. We are using GitHub flow and we have never squashed our commits in PRs. It is our policy for merging PRs.
Got it, thanks. This seems like a reasonable option to have for merge-based workflows. I've added it to our backlog.
For whoever picks this up: Here are the API docs for pulling commits, to figure out how to tell if something is a merge commit and therefore exclude it: https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28.
Problem Statement
I have noticed that when the "Suspect Commit" feature is used to identify the commit likely responsible for a bug, it often points to merge commits from the master or main branch, rather than the original commit where the changes were made. This complicates the process of accurately tracing the source of errors and understanding the specific changes that introduced them.
Could you advise if there is a way to configure the feature to bypass merge commits and directly target the actual change commits? If this is not currently possible, I believe it would be a beneficial enhancement to the functionality of your platform.
Solution Brainstorm
No response
Product Area
Issues