An error occurred fetching the project authors.
- 02 May, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
Initial Rails implementation was introduced in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16018, and acceptance testing was done in https://gitlab.com/gitlab-org/gitaly/issues/881 Part of https://gitlab.com/gitlab-org/gitaly/issues/817
-
- 01 May, 2018 1 commit
-
-
Ash McKenzie authored
-
- 03 Apr, 2018 1 commit
-
-
Ahmad Sherif authored
Closes gitaly#1110
-
- 23 Mar, 2018 1 commit
-
-
Jacob Vosmaer (GitLab) authored
-
- 21 Mar, 2018 1 commit
-
-
Jacob Vosmaer authored
-
- 13 Mar, 2018 2 commits
- 12 Mar, 2018 3 commits
-
-
Nick Thomas authored
-
Nick Thomas authored
-
Stan Hu authored
This is a workaround until we can ship git 2.16 with GitLab. Closes #5214
-
- 06 Mar, 2018 2 commits
-
-
Stan Hu authored
By default, --prune is added to the command-line of a git fetch operation, but for a new clone, this prune step isn't necessary. This change allows for that but does not actually change current behavior.
-
Stan Hu authored
By default, --prune is added to the command-line of a `git fetch` operation, but for repositories with many references this can take a long time to run. We shouldn't need to run --prune the first time we fetch a new repository.
-
- 15 Jan, 2018 1 commit
-
-
Ahmad Sherif authored
Closes gitaly#907
-
- 09 Jan, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
Migration is done through a small refactoring, which makes us call endpoins which are performing the same actions for namespaces. Tests are added to ensure only the project is removed that should be removed. Closes gitlab-org/gitaly#873
-
- 02 Jan, 2018 1 commit
-
-
Ahmad Sherif authored
Closes gitaly#825
-
- 14 Dec, 2017 2 commits
-
-
Nick Thomas authored
By importing this Ruby code into gitlab-rails (and gitaly-ruby), we avoid 200ms of startup time for each gitlab_projects subprocess we are eliminating. By not having a gitlab_projects subprocess between gitlab-rails / sidekiq and any git subprocesses (e.g. for fork_project, fetch_remote, etc, calls), we can also manage these git processes more cleanly, and avoid sending SIGKILL to them
-
Nick Thomas authored
By importing this Ruby code into gitlab-rails (and gitaly-ruby), we avoid 200ms of startup time for each gitlab_projects subprocess we are eliminating. By not having a gitlab_projects subprocess between gitlab-rails / sidekiq and any git subprocesses (e.g. for fork_project, fetch_remote, etc, calls), we can also manage these git processes more cleanly, and avoid sending SIGKILL to them
-