Commit api ignores page parameter when all is set to true
Summary
When using the gitlab api to retrieve all commits of a repository, setting the all parameter to true breaks pagination and returns the same data no matter what value the page parameter is set to. We believe this still worked properly around september last year.
Steps to reproduce
- Call /api/v4/projects/:id/repository/commits?page=10&all=true
- Call /api/v4/projects/:id/repository/commits?page=11&all=true
Both calls will produce the exact same response body
- Call /api/v4/projects/:id/repository/commits?page=10&all=false
- Call /api/v4/projects/:id/repository/commits?page=11&all=false
Both calls will have a different response body as they are correctly paged, however with the all parameter set to false we only get the commits of a single branch.
What is the current bug behavior?
Calls to /api/v4/projects/:id/repository/commits with all set to true do not return the correct body for pages, as they are always the same no matter the value of the page parameter
What is the expected correct behavior?
Calls to /api/v4/projects/:id/repository/commits with all set to true should return a different response body for each page.
Relevant logs and/or screenshots
Call to /api/v4/projects/455/repository/commits?page=10&all=true returns:
[
{
"id": "6e49986ade042bfbdd524b259c24c7ccde1f194a",
"short_id": "6e49986a",
"created_at": "2026-01-09T10:24:43.000+01:00",
...
Call to /api/v4/projects/455/repository/commits?page=11&all=true returns:
[
{
"id": "6e49986ade042bfbdd524b259c24c7ccde1f194a",
"short_id": "6e49986a",
"created_at": "2026-01-09T10:24:43.000+01:00",
...
Call to /api/v4/projects/455/repository/commits?page=10&all=false returns:
[
{
"id": "ffa7bc623a19335e84de62d2240232b1492448ee",
"short_id": "ffa7bc62",
"created_at": "2025-10-17T09:57:08.000+02:00",
...
Call to /api/v4/projects/455/repository/commits?page=11&all=false returns:
[
{
"id": "ccd707636795d1afba0e91fe9acb82e9644f86fd",
"short_id": "ccd70763",
"created_at": "2025-10-02T14:02:32.000+02:00",
...