PackRefs is not an expensive gitaly call - we want to
call it more often (than as part of full `gc`) because
it helps to keep number of refs files small - too many
refs file may be a problem for deployments with
slow storage.
EE added the ability to set timeouts when handling blobs. Since there's
no particular reason for this to be EE specific we can just backport
this to CE.
Prior to this change, this RPC had a fast_timeout. This timeout doesn't
set no timeout on Sidekiq. Deleting many refs can take over a couple of
seconds, so a default timeout would be neccesairy.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/49862
After trying to remove the whole method in
8f69014af2902d8d53fe931268bec60f6858f160, this is a more gentle
approach to the method. :)
Prior to this change, new commit detection wasn't implemented in Gitaly,
this was done through: https://gitlab.com/gitlab-org/gitaly/merge_requests/779
As the new implemented got moved around a bit, the whole RevList class
got removed.
Part of https://gitlab.com/gitlab-org/gitaly/issues/1233
As part of gitlab-org/gitaly#884, this commit contains the client
implementation for both TagNamesContaintingCommit and
BranchNamesContainingCommit. The interface in the Repository model stays
the same, but the implementation on the serverside, e.g. Gitaly, uses
`for-each-ref`, as opposed to `branch` or `tag` which both aren't
plumbing command. The result stays the same.
On the serverside, we have the opportunity to limit the number of names
to return. However, this is not supported on the front end yet. My
proposal to use this ability: gitlab-org/gitlab-ce#42581. For now, this
ability is not used as that would change more behaviours on a feature
flag which might lead to unexpected changes on page refresh for example.
GitLab Bot
Jan Provaznik
Yorick Peterse
gfyoung
Rubén Dávila
Zeger-Jan van de Weg
Alejandro Rodríguez
Andrew Newdigate
Ahmad Sherif
Douwe Maan
Jacopo
Jacob Vosmaer (GitLab)
Ahmad Sherif