- 15 6月, 2017 2 次提交
-
-
由 Eric Eastwood 提交于
Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/27070 Deprecate "chat commands" in favor of "slash commands" We looked for things like: - `slash commmand` - `slash_command` - `slash-command` - `SlashCommand`
-
由 Robert Speicher 提交于
-
- 01 6月, 2017 1 次提交
-
-
由 Douwe Maan 提交于
-
- 30 5月, 2017 1 次提交
-
-
由 Douwe Maan 提交于
-
- 24 5月, 2017 2 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 23 5月, 2017 1 次提交
-
-
由 Felipe Artur 提交于
-
- 13 5月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
I don't know why this happens exactly, but given an upstream and fork repository from a customer, both of which required GC, resolving conflicts would corrupt the fork so badly that it couldn't be cloned. This isn't a perfect fix for that case, because the MR may still need to be merged manually, but it does ensure that the repository is at least usable. My best guess is that when we generate the index for the conflict resolution (which we previously did in the target project), we obtain a reference to an OID that doesn't exist in the source, even though we already fetch the refs from the target into the source. Explicitly setting the source project as the place to get the merge index from seems to prevent repository corruption in this way.
-
- 12 5月, 2017 1 次提交
-
-
由 Valery Sizov 提交于
-
- 09 5月, 2017 1 次提交
-
-
由 Felipe Artur 提交于
-
- 08 5月, 2017 2 次提交
-
-
由 Felipe Artur 提交于
-
由 Felipe Artur 提交于
-
- 04 5月, 2017 2 次提交
-
-
由 Valery Sizov 提交于
-
由 Douwe Maan 提交于
-
- 25 4月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
The problem is that we often go via a diff object constructed from the diffs stored in the DB. Those diffs, by definition, don't overflow, so we don't have access to the 'correct' `real_size` - that is stored on the MR diff object iself.
-
- 20 4月, 2017 1 次提交
-
-
由 Valery Sizov 提交于
-
- 06 4月, 2017 4 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 04 4月, 2017 1 次提交
-
-
由 James Edwards-Jones 提交于
-
- 15 3月, 2017 1 次提交
-
-
由 Ruben Davila 提交于
-
- 06 3月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
The `ReferenceExtractor` would return an array of `ExternalIssue` objects, and then perform `Array#-` to remove the issues closed. `ExternalIssue`s had `==` defined, but not `hash` or `eql?`, which are used by `Array#-`.
-
- 01 3月, 2017 1 次提交
-
-
由 James Lopez 提交于
Rename column in the database Rename fields related to import/export feature Rename API endpoints Rename documentation links Rename the rest of occurrences in the code Replace the images that contain the words "build succeeds" and docs referencing to them Make sure pipeline is green and nothing is missing. updated doc images renamed only_allow_merge_if_build_succeeds in projects and fixed references more updates fix some spec failures fix rubocop offences fix v3 api spec fix MR specs fixed issues with partials fix MR spec fix alignment add missing v3 to v4 doc wip - refactor v3 endpoints fix specs fix a few typos fix project specs copy entities fully to V3 fix entity error more fixes fix failing specs fixed missing entities in V3 API remove comment updated code based on feedback typo fix spec
-
- 25 2月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
Previously, we created an unmergeable todo when a merge request: 1. Had merge when pipeline succeeds set. 2. Became unmergeable. However, when merge when pipeline succeeds fails due to unmergeability, the flag isn't actually removed. And a merge request can become unmergeable multiple times, as every time the target branch is updated we need to re-check the mergeable status. This means that if the todo was marked done, and the MR was checked again, a new todo would be created for the same event. Instead of checking this, we should create the todo from the service responsible for merging when the pipeline succeeds. That way the todo is guaranteed to only be created when we care about it.
-
- 23 2月, 2017 5 次提交
-
-
由 Douwe Maan 提交于
This reverts commit e00fb2bdc2090e9cabeb1eb35a2672a882cc96e9. # Conflicts: # .rubocop.yml # .rubocop_todo.yml # lib/gitlab/ci/config/entry/global.rb # lib/gitlab/ci/config/entry/jobs.rb # spec/lib/gitlab/ci/config/entry/factory_spec.rb # spec/lib/gitlab/ci/config/entry/global_spec.rb # spec/lib/gitlab/ci/config/entry/job_spec.rb # spec/lib/gitlab/ci/status/build/factory_spec.rb # spec/lib/gitlab/incoming_email_spec.rb
-
由 Douwe Maan 提交于
This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Sean McGivern 提交于
This was wrong when there were over 100 files in the diff, because we did not use the same diff options as subclasses of `Gitlab::Diff::FileCollection::Base` when getting the raw diffs. (The reason we don't use those classes directly is because they may perform highlighting, which isn't needed for just counting the diffs.)
-
- 07 2月, 2017 3 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 31 1月, 2017 1 次提交
-
-
由 Dongqing Hu 提交于
Remove MergeRequest#closes_issue?; Remove the default parameter value for #cache_merge_request_closes_issues! and #issues_mentioned_but_not_closing
-
- 20 1月, 2017 1 次提交
-
-
由 Robert Speicher 提交于
-
- 14 1月, 2017 1 次提交
-
-
由 twonegatives 提交于
-
- 13 1月, 2017 1 次提交
-
-
由 Jarka Kadlecova 提交于
-
- 11 1月, 2017 1 次提交
-
-
由 Jarka Kadlecova 提交于
-
- 03 1月, 2017 1 次提交
-
-
由 James Lopez 提交于
Also added relevant specs and refactored to_references in a bunch of places to be more consistent.
-
- 28 12月, 2016 1 次提交
-
-
由 Gabriel Gizotti 提交于
use MergeRequest#closes_issues instead of rewriting code to retrieve closing issues on MergeRequest#issues_mentioned_but_not_closing
-