"Upcoming Dependabot comment command deprecations" feedback

[qgustavor]

Select Topic Area

Product Feedback

Body

Related GitHub Changelog post: https://github.blog/changelog/2025-10-06-upcoming-changes-to-github-dependabot-pull-request-comment-commands/.

My feedback: I'm an avid @dependabot merge user so, of course, I don't like this. Commenting on the arguments, "reduce confusion" makes sense because "why the bot handles that?", and "improve reliability" makes sense because it wasn't the bot's job in the first place, separation of concerns is important. I don't get the "encourage use of the GitHub platform’s built-in tools", why? People using the command surely knew they would use the tools, it was just other way to do.

Then, it makes me think: why people using those commands use them? In my case, because it's a way of quickly merging dependabot's PR's within my e-mail client without I having to open GitHub. I guess some people probably even automated this step and made automatons to reply dependabot's mails with @dependabot merge, because, let's be fair, I never check if their PR's will break things and that's why some of my projects I don't have time to maintain have their CI's broken.

But, again, separation of concerns is important, so I guess the issue here is: why people are using those commands in the first place?

If people are using it because e-mail, then GitHub could make those commands work via e-mail for any PR, not just dependabot's. If people prefer a text interface (for whatever reason), it could be implemented in a way that still allows for separation of concerns. Other people can give their feedback on this thread, of course.

Considering how my feedback on the automatic watching of repositories went (it got ignored, the feature got deprecated and I know at least two developers that had issues because of this) I don't expect this deprecation to be reversed, so I will disable dependabot from my projects, as it's annoying to having to open GitHub just to approve PRs that often only fixes issues that don't affect my projects. As my FOSS projects are mostly static websites hosted on GitHub Pages, fixing any vuln with "Attack Vector = Network" is often just a matter to "ok, let's fix it so npm stop whinning whenever I do npm install".

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[pglombardo]

I would simplify and just say that I've relied on this functionality for years and it has always worked flawlessly. It's been an important part of code workflows to automatically merge security issues and minor dependency updates.

I don't understand the reasoning to remove it because none was shared and to add, no alternative was provided.

"Please update your workflows to rely on GitHub’s native features" I thought this was a native feature...

The way this change has been communicated makes the removal seem senseless and without valid motive.

[felsokning]

"This change is intended to reduce confusion, improve reliability, and encourage use of the GitHub platform’s built-in tools for working with pull requests."

This statement comes across as a problematic for a myriad of reasons. Let's break them down:

1. Reduce confusion - Is the inference that users who use these commands don't understand what they do, so GitHub has to intervene on behalf of "confused users"? Squash and merge, a setting that you can apply to the default behaviour of a pull request - for example, doesn't use any language or contextual information that's any different than actually configuring a pull request to always be squashed and merged. So, the question becomes, because this is the vernacular that you've specifically chosen to use, how is there confusion introduced when the words/meanings are the exact same thing? Is the inference that users get confused about what a merge versus a squash and merge and the like are? If so, wouldn't the issue actually be the vernacular chosen for the PR merge types and not the commands, themselves? In other words, the specific vernacular you've chosen is pretty damning because it infers that the users who use your bot get confused around the commands, which happens to use the same vernacular/language/wording of the pull request behaviours. How can users get "confused" in one context but not another?
2. Improve reliability - Removing a feature does not improve the reliability of that feature or the reliability of the overall product. It merely reduces your responsibility of supporting that feature to nothing and, thus, the only "improvements to reliability" are the areas of the code you now have to touch to support the dependabot. For example, taking "squash and merge" as command, if the squash and merge via the PR UI is broken, you've actually reduced the surface that can be used to achieve this goal; so, if anything, you're actually making reliability worse - not better. Feel free to correct me, if I'm wrong. Worth noting about reliability is that the documentation for the commands hasn't been changed for this deprecation. So, in about a month's time, your own documentation will give this commands that the bot will no longer support.
3. Encourage use of the GitHub platform’s built-in tools for working with pull requests - This seems to be the penultimate reason for this change. Some PM saw that the use of the web interface was actually going down because of the use of the bot commands and decided that this wouldn't do, because the "impact" is driving downwards on the use of their features and, thus, they've lost a key metric for their end of the year reviews. Given that dependabot is a bot written by Microsoft and is one of Microsoft's "built-in tools" to be used on GitHub (literally have documentation on Github for this specific bot versus, say, renovate) this seems to cause a cognitive dissonance around "encouraging built-in tools" because you're saying one built-in tool > than another. If the focus is on GitHub's "built-in tools" (herein, meaning the UI, so far), why wouldn't the assumption be that you're eventually going to scrap dependabot altogether for some AI integration, in the future, and that we shouldn't just dump the bot, entirely, now? After all, the features of a built-in tool for GitHub (dependabot) are being deprecated for features of another built-in tool (the PR UI), which doesn't imply/infer these sorts of deprecations will stop here - so long as someone else gets a say/control over your team's features.

I really hope that this statement is just the result of poor wording by someone who's unfamiliar with the tool and it's use because, otherwise, it comes across as pretty condescending and tone-deaf to the actual users of the bot.

[WIStudent]

GitHub’s built-in merge tools are not an adequate replacement for @dependabot merge in my opinion. With @dependabot merge I can review multiple dependabot PRs, add @dependabot merge comments to the ones I want to merge, and leave the actual merging and rebasing to dependabot. With GitHub's merge tools, merging one dependabot PRs often causes merge conflicts on other Dependabot PRs (because of changes to files like package-lock.json), so once I merged one PR, I have to wait for dependabot to rebase the other PRs (or tell it to do it with @dependabot rebase) before I can merge the next dependabot PR.

[slifty]

I opened a related discussion here: dependabot/dependabot-core#13266

I'll add another example use of the merge command, which I mention in that discussion:

I had been relying on @dependabot merge to help protect my projects from dependabot phishing attacks on my repository -- the logic being that if someone attempts to credibly APPEAR as dependabot opens a PR, and I fail to detect that spoofing in my review, @dependabot merge would be a final safeguard because the attacker would not have the rights to merge.

Another use case: My repositories require an approval (including dependabot). The flow I had used was "review code, approve, and include @dependabot merge in my approval message).

With this change I'll need to approve, then go back to the ticket and manually merge (or I'll need to click the big "bypass branch restrictions" button which is a habit I NEVER want to get in as it risks accidentally bypassing other restrictions such as CI.