Why does TeamCity, when rebase git, rebuild commits that it has already collected before?

Question

Java

Actually a question.
If you do a git rebase, for some reason the TS thinks that new commits have arrived. And puts them in a queue.
Therefore, if the developer worked on the branch for a month, and then made a rebase, then the queue is instantly filled with a hundred other builds. What a sadness. And if there are several such branches at the same time, the sadness is multiple. And also each build for a few (yet) minutes.
Although the history shows that he already collected these commits and merdzhi.
Google advised to uncheck Triggers - VCS Trigger - Per-checkin Triggering - "Include several checkins in a build if they are from the same commiter".
But this did not help, as far as I understand, the jackdaw is responsible for ensuring that one build is assembled from one committer (dever), despite several commits - which actually should speed up the process a little.
I don't want to uncheck "Trigger a build on each check-in" either, so it will be clear who messed up - because the project is growing very quickly and filled with people who mess up ))
Bitbucket is used as git. There is also a restriction on merge without a green build.
I can't figure out what the hell is this? I understand that the git does not care, I made commits according to my own rules. Why isn't TC tracking this?
How to cure it, who faced?
TC 9.1, Bitbucket 4.8.3

Answer 1

If you do a git rebase, for some reason the TS thinks that new commits have arrived.

Because rebase creates new commits.