An error occurred fetching the project authors.
- 09 May, 2018 1 commit
-
-
Douwe Maan authored
-
- 07 May, 2018 2 commits
-
-
Tiago Botelho authored
-
Tiago Botelho authored
-
- 25 Apr, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
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
-
- 14 Apr, 2018 1 commit
-
-
Stan Hu authored
-
- 28 Mar, 2018 2 commits
-
-
Takuya Noguchi authored
-
Jacob Vosmaer (GitLab) authored
-
- 07 Mar, 2018 2 commits
-
-
Stan Hu authored
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 authored
-
- 06 Mar, 2018 2 commits
-
-
Ahmad Sherif authored
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 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.
-
- 05 Mar, 2018 1 commit
-
-
Ahmad Sherif authored
Closes gitaly#1054
-
- 01 Mar, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
Part of the migration as tracked in: gitlab-org/gitaly#1026
-
- 23 Feb, 2018 1 commit
-
-
Tiago Botelho authored
-
- 17 Feb, 2018 1 commit
-
-
Douwe Maan authored
-
- 14 Feb, 2018 4 commits
-
-
Stan Hu authored
-
Stan Hu authored
-
Stan Hu authored
-
Stan Hu authored
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 Feb, 2018 1 commit
-
-
Rubén Dávila authored
-
- 06 Feb, 2018 1 commit
-
-
Bastian Blank authored
Signed-off-by: Bastian Blank <waldi@debian.org>
-
- 02 Feb, 2018 1 commit
-
-
Ahmad Sherif authored
Gitlab::Git::Repository#find_branch has a similar logic. Fixes #42609
-
- 01 Feb, 2018 1 commit
-
-
Zeger-Jan van de Weg authored
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.
-
- 30 Jan, 2018 4 commits
-
-
Ahmad Sherif authored
Fixes #42544
-
Jacob Vosmaer authored
-
Jacob Vosmaer (GitLab) authored
-
Kim "BKC" Carlbäcker authored
-
- 25 Jan, 2018 1 commit
-
-
Jacob Vosmaer authored
-
- 24 Jan, 2018 2 commits
-
-
Ahmad Sherif authored
Closes gitaly#946
-
Ahmad Sherif authored
Closes gitaly#929
-
- 22 Jan, 2018 1 commit
-
-
Kim "BKC" Carlbäcker authored
-
- 18 Jan, 2018 1 commit
-
-
Kim "BKC" Carlbäcker authored
-
- 16 Jan, 2018 2 commits
-
-
Sean McGivern authored
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 authored
-
- 15 Jan, 2018 4 commits
-
-
Andrew McCallum authored
-
Andrew McCallum authored
-
Andrew McCallum authored
-
Andrew McCallum authored
-
- 12 Jan, 2018 1 commit
-
-
Lin Jen-Shin authored
with StrongMemoize
-
- 11 Jan, 2018 1 commit
-
-
🙈 jacopo beschi 🙉 authored
-