- 10 5月, 2018 1 次提交
-
-
由 Douwe Maan 提交于
-
- 07 5月, 2018 2 次提交
-
-
由 Tiago Botelho 提交于
-
由 Tiago Botelho 提交于
-
- 25 4月, 2018 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
Direct disk access is done through Gitaly now, so the legacy path was deprecated. This path was used in Gitlab::Shell however. This required the refactoring in this commit. Added is the removal of direct path access on the project model, as that lookup wasn't needed anymore is most cases. Closes https://gitlab.com/gitlab-org/gitaly/issues/1111
-
- 15 4月, 2018 1 次提交
-
-
由 Stan Hu 提交于
-
- 28 3月, 2018 2 次提交
-
-
由 Takuya Noguchi 提交于
-
由 Jacob Vosmaer (GitLab) 提交于
-
- 07 3月, 2018 2 次提交
-
-
由 Stan Hu 提交于
We saw that in a customer instance, `empty?` was cached to be `true` even though `has_visible_content?` and `exists?` were `true`. This double caching can run into edge cases because there's no guarantee that the inner values will properly expire the outer one, especially if there is Redis replication lag. Consider this scenario: 1. `exists?` and `has_visible_content?` are false 2. `empty?` is expired 3. A subsequent call to `empty?` returns `true` because `exists?` is false even though `empty` is true 4. `exists?` and `has_visible_content?` are then expired 5. `exists?` and `has_visible_content?` are set to true 6. `empty?` is still stuck in the wrong value as `true` Closes #43882
-
由 Alejandro Rodríguez 提交于
-
- 06 3月, 2018 3 次提交
-
-
由 Ahmad Sherif 提交于
Fixes gitaly#1057 The old code was calling LastCommitForPath to extract a commit ID _then_ call FindCommit to get a commit it already had in the first place!
-
由 Stan Hu 提交于
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.
-
由 Ahmad Sherif 提交于
Closes gitaly#1054
-
- 01 3月, 2018 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
Part of the migration as tracked in: gitlab-org/gitaly#1026
-
- 23 2月, 2018 1 次提交
-
-
由 Tiago Botelho 提交于
-
- 17 2月, 2018 1 次提交
-
-
由 Douwe Maan 提交于
-
- 15 2月, 2018 4 次提交
-
-
由 Stan Hu 提交于
-
由 Stan Hu 提交于
-
由 Stan Hu 提交于
-
由 Stan Hu 提交于
We removed the exception handling for Rugged errors in !16770, which revealed that the licensee gem attempts to retrieve a license file via Rugged in `refs/heads/master` by default. If that branch did not exist, a Rugged::ReferenceError would be thrown. There were two issues: 1. Not every project uses `master` as the default branch. This change uses the head commit to identify the license. 2. Removing the exception handling caused repositories to fail loading. We can safely catch and ignore any Rugged error because this means we weren't able to load a license file. Closes #43268
-
- 07 2月, 2018 2 次提交
-
-
由 Rubén Dávila 提交于
-
由 Bastian Blank 提交于
Signed-off-by: NBastian Blank <waldi@debian.org>
-
- 03 2月, 2018 1 次提交
-
-
由 Ahmad Sherif 提交于
Gitlab::Git::Repository#find_branch has a similar logic. Fixes #42609
-
- 01 2月, 2018 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
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.
-
- 31 1月, 2018 3 次提交
-
-
由 Ahmad Sherif 提交于
Fixes #42544
-
由 Jacob Vosmaer 提交于
-
由 Jacob Vosmaer (GitLab) 提交于
-
- 30 1月, 2018 1 次提交
-
-
由 Kim "BKC" Carlbäcker 提交于
-
- 25 1月, 2018 2 次提交
-
-
由 Jacob Vosmaer 提交于
-
由 Ahmad Sherif 提交于
Closes gitaly#946
-
- 24 1月, 2018 1 次提交
-
-
由 Ahmad Sherif 提交于
Closes gitaly#929
-
- 22 1月, 2018 1 次提交
-
-
由 Kim "BKC" Carlbäcker 提交于
-
- 19 1月, 2018 1 次提交
-
-
由 Kim "BKC" Carlbäcker 提交于
-
- 16 1月, 2018 2 次提交
-
-
由 Sean McGivern 提交于
A file containing /:\d+:/ in its contents would break the search results if those contents were part of the results, because we were splitting on colons, which can't work with untrusted input. Changing to use the null byte as a separator is much safer.
-
由 Andrew McCallum 提交于
-
- 15 1月, 2018 4 次提交
-
-
由 Andrew McCallum 提交于
-
由 Andrew McCallum 提交于
-
由 Andrew McCallum 提交于
-
由 Andrew McCallum 提交于
-
- 12 1月, 2018 2 次提交
-
-
由 Lin Jen-Shin 提交于
with StrongMemoize
-
由 🙈 jacopo beschi 🙉 提交于
-