It is very useful in work cultures where people don't do PRs all the time (particularly out of laziness or to do hotfixes), but you still want to comment on the change.

We do PRs for all changes, but strongly prefer to have comments about a particular commit within a PR be attached to the commit, and not just to the PR.

With this change, if we have comments about a given commit in a PR, we will now have to manually add a link to that commit in the comment so the developer knows which commit the comment is referring to.

It wouldn't be as much of an issue if PR-level code review was easier. As it stands now, the multi-commit view they just added (which is a step in the right direction) is still useless to us because it includes merges commits as well, which is not that developer's code.

So PR-level code review is still a non-starter, and commit-level code review just got clunkier.

I get that they can't support every possible workflow, but they could have at least given us a warning they were going to pull support for a feature we use (they do have those metrics) or at very least acknowledge it somewhere.

As a workaround you could just attach the comment to the very first or last line in the commit diff. Of course, this won't work for commits that consist entirely of non-diffable binary files, but it should work ok in most cases.