Intelligent 'Dismiss stale approvals when new commits are pushed' #12876
-
|
There is a Github branch protection setting called "Dismiss stale pull request approvals when new commits are pushed". Unfortunately, this one won't allow a workflow with fixup and squash commits. Feature RequestDuring a PR review with it's common that 1-2 fixup commits are added to address reviewer concerns. It would be good if the PR approvals were not dismissed, in the scenario where commits are squashed, but no actual files has changed, i.e. there are no code changes, only commits being moved around or merged. Example Scenario
Solution: Would be great if a SHA-hash of the entire diff (or each individual touched file in PR) was compared instead, and if they are identical the existing approval is not considered stale, even if commits have changed.
|
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 18 replies
-
|
While this may seem to be a minor feature it would improve development flows a lot at low cost |
Beta Was this translation helpful? Give feedback.
-
|
Write directly to Github (their product feedback form) and let them know. They rarely read this forum. |
Beta Was this translation helpful? Give feedback.
-
|
Rebasing my changes with latest commit without any code change should not lead to dismissal of review either. This promotes people to push stale code v/s getting their code reviewed again. |
Beta Was this translation helpful? Give feedback.
-
|
I'm pretty sure that as of today, an "update with rebase" (at least via the UI) does not require re-review, even if "dismiss stale approvals when new commits are pushed" is enabled. |
Beta Was this translation helpful? Give feedback.
-
|
That's not what this is about. It's about the scenario where you have a few "fixup! My other commit" commits present when the PR was approved. But as a last step before merging, you want to squash them in (but the actual file diff across the full PR is unchanged). Doing so will invalidate the review. |
Beta Was this translation helpful? Give feedback.
-
|
I know that it doesn't fix your issue with fixup/squash, but the rebase issue has been fixed. |
Beta Was this translation helpful? Give feedback.
-
|
But you can squash through the interface and it will work. I know it doesn't provide all the possibilities like doing through the UI, but it works relatively well. Also, squashing changes the tree, so it identifies as a new commit. Fixing this would have to change from very easy checks (approved commit) by checking the whole contents change |
Beta Was this translation helpful? Give feedback.
-
|
This request fixes an incessant annoyance for me. |
Beta Was this translation helpful? Give feedback.
-
|
Write directly to Github (their product feedback form) and let them know. They rarely read this forum. |
Beta Was this translation helpful? Give feedback.
-
|
If even Bitbucket can do it then surely GitHub can? 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
I also found this surprising as GitHub's feature set is far superior in every other aspect. |
Beta Was this translation helpful? Give feedback.
-
|
The problem i see is this , our branch is defined to be up-to-date , so if someone approved my PR and i need to rebase the approval goes away, this is very annoying as it might happen couple of times a day. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
That's not what this issue is about. See the text under "Example Scenario" above. It's about squashing commits together, even though the overall diff for the PR remains unchanged. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback. As part of the security changes we made to review policies (see this blog post), we also enabled the use-cases you are asking about:
...or any combination of those operations. Regards, Daryl |
Beta Was this translation helpful? Give feedback.
-
|
A very obvious use case that's missing is when applying suggestions. I.e.:
|
Beta Was this translation helpful? Give feedback.
-
|
It would be nice to have a manifest of files that would require re-approval if changed. Would also be nice to have some sort of configuration for Levenshtein distance threshold between files in last commit vs the latest commit. |
Beta Was this translation helpful? Give feedback.
-
|
@DarylCantrell |
Beta Was this translation helpful? Give feedback.
-
|
@tm-slavik57 I wrote an action that handles the rebase case: https://github.com/withgraphite/dismiss-stale-approvals |
Beta Was this translation helpful? Give feedback.
-
|
The use case that @dalmolinz described is feature requested here: https://github.com/orgs/community/discussions/78039 |
Beta Was this translation helpful? Give feedback.
@sandstrom @shlomiken
Thanks for the feedback. As part of the security changes we made to review policies (see this blog post), we also enabled the use-cases you are asking about:
...or any combination of those operations.
Regards, Daryl