- 06 3月, 2018 1 次提交
-
-
由 Francisco Javier López 提交于
-
- 01 3月, 2018 1 次提交
-
-
由 Jean-Baptiste Guerraz 提交于
-
- 12 2月, 2018 1 次提交
-
-
由 Valery Sizov 提交于
-
- 07 2月, 2018 2 次提交
-
-
由 Rubén Dávila 提交于
-
由 Nick Thomas 提交于
-
- 02 2月, 2018 2 次提交
-
-
由 James Lopez 提交于
-
由 Micaël Bergeron 提交于
-
- 26 1月, 2018 3 次提交
-
-
由 James Lopez 提交于
-
由 James Lopez 提交于
-
由 James Lopez 提交于
-
- 17 1月, 2018 1 次提交
-
-
由 James Lopez 提交于
[10.3] Fix RCE via project import mechanism See merge request gitlab/gitlabhq!2294 (cherry picked from commit dcfec507d6f9ee119d65a832393e7c593af1d3b2) 86d75812 Fix RCE via project import mechanism
-
- 11 1月, 2018 1 次提交
-
-
由 Jan Provaznik 提交于
For each MR diff an extra 'SELECT COUNT()' is executed to get number of commits for the diff. Overall time to get counts for all MR diffs may be quite expensive. To speed up loading of MR info, information about number of commits is stored in a MR diff's extra column. Closes #38068
-
- 09 1月, 2018 1 次提交
-
-
由 Yorick Peterse 提交于
This removes all usage of soft removals except for the "pending delete" system implemented for projects. This in turn simplifies all the query plans of the models that used soft removals. Since we don't really use soft removals for anything useful there's no point in keeping it around. This _does_ mean that hard removals of issues (which only admins can do if I'm not mistaken) can influence the "iid" values, but that code is broken to begin with. More on this (and how to fix it) can be found in https://gitlab.com/gitlab-org/gitlab-ce/issues/31114. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37447
-
- 05 1月, 2018 4 次提交
-
-
由 Grzegorz Bizon 提交于
-
由 Grzegorz Bizon 提交于
-
由 Grzegorz Bizon 提交于
-
由 Matija Čupić 提交于
-
- 04 1月, 2018 2 次提交
-
-
由 Grzegorz Bizon 提交于
-
由 Grzegorz Bizon 提交于
-
- 25 12月, 2017 1 次提交
-
-
由 Matija Čupić 提交于
-
- 22 12月, 2017 1 次提交
-
-
由 blackst0ne 提交于
-
- 29 11月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
The st_commits and st_diffs columns on merge_request_diffs historically held the YAML-serialised data for a merge request diff, in a variety of formats. Since 9.5, these have been migrated in the background to two new tables: merge_request_diff_commits and merge_request_diff_files. That has the advantage that we can actually query the data (for instance, to find out how many commits we've stored), and that it can't be in a variety of formats, but must match the new schema. This is the final step of that journey, where we drop those columns and remove all references to them. This is a breaking change to the importer, because we can no longer import diffs created in the old format, and we cannot guarantee the export will be in the new format unless it was generated after this commit.
-
- 24 11月, 2017 1 次提交
-
-
由 James Lopez 提交于
-
- 23 11月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
Compared to the merge_request_diff association: 1. It's simpler to query. The query uses a foreign key to the merge_request_diffs table, so no ordering is necessary. 2. It's faster for preloading. The merge_request_diff association has to load every diff for the MRs in the set, then discard all but the most recent for each. This association means that Rails can just query for N diffs from N MRs. 3. It's more complicated to update. This is a bidirectional foreign key, so we need to update two tables when adding a diff record. This also means we need to handle this as a special case when importing a GitLab project. There is some juggling with this association in the merge request model: * `MergeRequest#latest_merge_request_diff` is _always_ the latest diff. * `MergeRequest#merge_request_diff` reuses `MergeRequest#latest_merge_request_diff` unless: * Arguments are passed. These are typically to force-reload the association. * It doesn't exist. That means we might be trying to implicitly create a diff. This only seems to happen in specs. * The association is already loaded. This is important for the reasons explained in the comment, which I'll reiterate here: if we a) load a non-latest diff, then b) get its `merge_request`, then c) get that MR's `merge_request_diff`, we should get the diff we loaded in c), even though that's not the latest diff. Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases, but not quite all.
-
- 20 11月, 2017 1 次提交
-
-
由 Yorick Peterse 提交于
This adds various foreign keys and indexes to the "merge_requests" table as outlined in https://gitlab.com/gitlab-org/gitlab-ce/issues/31825. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/31825
-
- 07 11月, 2017 4 次提交
-
-
由 James Lopez 提交于
-
由 James Lopez 提交于
Added unit test and updated integration spec to test for this as well.
-
由 Alessio Caiazza 提交于
-
由 Alessio Caiazza 提交于
-
- 06 11月, 2017 1 次提交
-
-
由 Markus Koller 提交于
-
- 03 11月, 2017 4 次提交
-
-
由 micael.bergeron 提交于
also, I refactored the MergeRequest#fetch_ref method to express the side-effect that this method has. MergeRequest#fetch_ref -> MergeRequest#fetch_ref! Repository#fetch_source_branch -> Repository#fetch_source_branch!
-
由 Shinya Maeda 提交于
-
由 Shinya Maeda 提交于
-
由 Shinya Maeda 提交于
-
- 02 11月, 2017 1 次提交
-
-
由 Shinya Maeda 提交于
Fix out of sync with KubernetesService. Remove namespace pramas from controller. Use time_with_zone in schema. Remove Gcp::Clusters from safe_model_attributes.ym
-
- 01 11月, 2017 1 次提交
-
-
由 Shinya Maeda 提交于
-
- 31 10月, 2017 3 次提交
-
-
由 James Lopez 提交于
-
由 James Lopez 提交于
-
由 James Lopez 提交于
-
- 14 10月, 2017 1 次提交
-
-
由 Matt Coleman 提交于
-