Cleanup redundant refs/keep-around
This was brought up by @DouweM in https://gitlab.com/gitlab-org/gitlab-ce/issues/36803#note_38287997
I wonder if we could somehow figure out which keep-around refs are redundant. If I (non-force) push into an MR's branch 3 times, I end up with 3 keep-around refs, but we really only need the latest, since the first 2 commits are ancestors of that commit and will automatically be kept around too.
Of course iterating over all keep-around refs and checking
is_ancestor?
(throughmerge_base
) for each combination of them smells likeO(n^2)
...
And @smcgivern has a good point about backtracking in https://gitlab.com/gitlab-org/gitlab-ce/issues/36803#note_38289027
interesting point! I think that could definitely work if we could do it efficiently. It also worries me a little. Say we allow deleting a commit in future (by removing all hidden refs pointing to it, and the associated DB objects if necessary) as per https://gitlab.com/gitlab-org/gitlab-ce/issues/19376.
Assume that we have
abc -> abd -> abe
, and have refs pointing to each of these revisions.
Under this scheme, we'd've only kept around
abe
(because the others are redundant), but then if you deleteabe
, we'd need to somehow figure out that we need to create a ref pointing toabd
again.
I don't think this is insurmountable, but we'd need to do that tracking somewhere (commits table + a references table? It's possible this would also make the redundant ref calculation faster).