<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=389582) </details> <!--IssueSummary end--> We're on Gitlab Premium self hosted 15.7.5ee (we update every other week). We use the commits API in CI pipelines to dynamically determine the version number as the # of commits to the `main` branch. Some of our repos exceed `100` commits, which is the maximum page size. For those repos we found that the commits API was not properly setting the `x-total-pages` header, thus the standard pattern we use for paginating through results was not working. It looks like this was [broken intentionally](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43159) for performance reasons. We have a temporary workaround of comparing the `x-next-page` and `x-current-page` headers, but we are concerned that this will be broken in the future as well as the potential strain this puts on our webservice pods for our Gitlab instance. We don't need the actual commits, just the total number. The `statistics` that hang off the projects API won't work because they aren't always up to date - they can lag by as much as [15 minutes](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26854). Can we either get a feature flag to re-enable appropriate pagination on the commits API or have a new always-up-to-date attribute called like `total_commits` added to the [branches API](https://docs.gitlab.com/ee/api/branches.html)? Open to other workarounds as long as they are: * able to be called via the REST API * Always up to date Lastly, I suggest that the docs and code for the commits API be updated to be clear that it doesn't support pagination rather than partially supporting it.