### Summary When fetching commits from the `/api/v4/projects/:id/repository/commits` endpoint with the `all=true` parameter and pagination, the API returns duplicate commit objects across multiple pages. This results in the final dataset containing significantly fewer unique commits than the total item count suggests. ### Steps to reproduce 1. Use a repository with multiple branches (e.g., 10+ branches) and >100 unique commits distributed across them. 2. Query the Commits API using the `all=true` parameter and a specific page size: `GET /api/v4/projects/:id/repository/commits?all=true&per_page=50&page=1` 3. Fetch the second page: `GET /api/v4/projects/:id/repository/commits?all=true&per_page=50&page=2` 4. Compare the commit SHAs from Page 1 and Page 2. 5. **Observation:** Several SHAs present in Page 1 will appear again in Page 2. ### Example Project *N/A - Reproduced on private repository. Behaviour is consistent on repositories with high branch counts and overlapping commit histories.* ### What is the current bug behavior? The API returns the same commits multiple times across different paginated result sets. For example, in a test case with 1041 total items reported across 11 pages, only 100 unique commit SHAs were actually retrieved because of duplicates on subsequent pages. ### What is the expected correct behavior? * Each page should contain unique commits relative to the other pages in the same request sequence. * The sum of unique commits should match (or be close to) the total commit count. * Pagination should allow for a complete, non-redundant traversal of the repository's commit history across all branches. ### Relevant logs and/or screenshots **Example API Response discrepancy:** * **Total items reported:** 1041 * **Actual unique SHAs collected:** 100 * **Endpoint:** `/api/v4/projects/:id/repository/commits?all=true` ### Output of checks #### Results of GitLab environment info * **GitLab Version:** GitLab.com (SaaS) * **API Version:** v4 ### Possible fixes The issue likely stems from unstable sorting when `all=true` is used. Because commits are being pulled from multiple refs, the default sort (likely `committed_date`) may have many "ties" (commits with the same timestamp). **Recommendation:** Implement a deterministic tie-breaker in the underlying database query (e.g., sorting by `committed_date` DESC, then `id` or `sha` DESC) to ensure that the cursor/offset remains consistent across paginated requests.