Ease n+1 calls on diverging_commit_counts for BranchesController#index
This was originally filed at https://gitlab.com/gitlab-org/gitlab-ce/issues/37429 and this issue is trying to focus on the part for:
app/controllers/projects/branches_controller.rb#index
-> app/models/repository.rb#diverging_commit_counts
-> Gitlab::Git::Repository.rb#count_commits_between
-> Gitlab::Git::Commit#between
@godfat said:
I think we should also stop showing information like this:
Because:
- It's hard to scale it
- It's hard to cache and invalidate it (hard be both accurate and fast)
- It's not useful anyway
It would be nice if we could detect that if the information could be retrieve fast enough, we would still show it. Like some data count would just show you that it's more than 10000 or so.
@rymai said:
We could probably say if
branch.dereferenced_target.committed_date > 6.months.ago
, we don't retrieve the "commits behind count" and show "XYZ+" whereXYZ
would be equal togit rev-list --after="<6 months ago>" --count <ref_root>
, potentially rounded to the nearest integer, e.g.n.round(-(n.to_s.size - 2)) if n > 99
.The idea is that "behind commits count" always increase with time so if a branch last commit is x months ago, we can assume:
It's probably stale, so the "diverging commits count" is less useful
If the last commit was precisely 6 months ago, and it was rebased upon the root ref, it means the "commit behind count" is equal to the number of commits on the root ref since 6 months ago
If the last commit was not a rebase or is older than 6 months ago, then the "commit behind count" is de facto > to the number of commits on the root ref since 6 months ago
Commits ahead could still be retrieved and displayed (but we could also just not show them at all if the branch is stale!)
For branches updated in the last 6 months, we would still display the exact count.
Of course, "6 months" is arbitrary, we could choose another timespan (e.g. 2 months).
On the other hand, we're introducing the concept of a stale branch at https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15402, which is using 3 months as the threshold. We should probably align the concept.