- 05 12月, 2017 3 次提交
-
-
由 Felipe Artur 提交于
-
由 Felipe Artur 提交于
-
由 Jarka Kadlecova 提交于
-
- 30 11月, 2017 1 次提交
-
-
由 Lin Jen-Shin 提交于
-
- 29 11月, 2017 2 次提交
-
-
由 Sean McGivern 提交于
If a merge request was created with a branch name that also matched a tag name, we'd generate a comparison to or from the tag respectively, rather than the branch. Merging would still use the branch, of course. To avoid this, ensure that when we get the branch heads, we prepend the reference prefix for branches, which will ensure that we generate the correct comparison.
-
由 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.
-
- 26 11月, 2017 1 次提交
-
-
由 George Andrinopoulos 提交于
-
- 24 11月, 2017 1 次提交
-
-
由 Felipe Artur 提交于
-
- 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.
-
- 13 11月, 2017 1 次提交
-
-
由 George Andrinopoulos 提交于
-
- 12 11月, 2017 1 次提交
-
-
由 George Andrinopoulos 提交于
-
- 10 11月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
When we consider 'all' pipelines for MRs, we now mean: 1. The last 10,000 commits (unordered). 2. From the last 100 MR versions (newest first). This seems to fix the MRs that time out on GitLab.com.
-
- 08 11月, 2017 1 次提交
-
-
由 Douwe Maan 提交于
Use Commit#notes and Note.for_commit_id when possible to make sure we use all the indexes available to us
-
- 07 11月, 2017 1 次提交
-
-
由 Jarka Kadlecova 提交于
-
- 06 11月, 2017 1 次提交
-
-
由 micael.bergeron 提交于
reword the changelog remove dead code in the specs
-
- 03 11月, 2017 1 次提交
-
-
由 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!
-
- 02 11月, 2017 1 次提交
-
-
由 Jarka Kadlecova 提交于
-
- 30 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 28 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 27 10月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
For MRs with many thousands of commits, `SELECT DISTINCT(sha)` will be very slow. What we can't do to fix this: 1. Add an index. Postgres won't use it for DISTINCT without a lot of ceremony. 2. Do the `uniq` in Ruby. That can still be very slow with hundreds of thousands of commits. 3. Use a subquery. We haven't removed the `st_commits` column yet, but we will soon. Until 3 is available to us, we can just do 2, but also add a limit clause. There is no ordering, so this may return different results, but our goal with these MRs is just to get them to load, so it's not a huge deal.
-
- 13 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 12 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 10 10月, 2017 1 次提交
-
-
由 Andrew Newdigate 提交于
-
- 09 10月, 2017 3 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 07 10月, 2017 2 次提交
-
-
由 Bob Van Landuyt 提交于
-
由 Toon Claes 提交于
In GitLab EE, a GitLab instance can be read-only (e.g. when it's a Geo secondary node). But in GitLab CE it also might be useful to have the "read-only" idea around. So port it back to GitLab CE. Also having the principle of read-only in GitLab CE would hopefully lead to less errors introduced, doing write operations when there aren't allowed for read-only calls. Closes gitlab-org/gitlab-ce#37534.
-
- 05 10月, 2017 1 次提交
-
-
由 Rémy Coutable 提交于
MergeRequest#create_merge_request_diff and MergeRequest#reload_diff are the only places where we generate a new MR diff so that's where we should fetch the ref. This also ensures that the ref is not fetched when we call merge_request.merge_request_diffs.create in Github::Import#fetch_pull_requests. Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 04 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 02 10月, 2017 1 次提交
-
-
由 Yorick Peterse 提交于
In this particular case the use of UNION ALL leads to a better query plan compared to using 1 big query that uses an OR statement to combine different data sources. See https://gitlab.com/gitlab-org/gitlab-ce/issues/38508 for more information.
-
- 30 9月, 2017 1 次提交
-
-
由 Eric Eastwood 提交于
-
- 19 9月, 2017 2 次提交
-
-
由 Yorick Peterse 提交于
This ensures the open issues/MR count caches are refreshed properly when creating new issues or MRs. This MR also includes a change to the cache keys to ensure all caches are rebuilt on the fly. This particular problem was not caught in the test suite due to a null cache being used, resulting in all calls that would use a cache using the underlying data directly. In production the code would fail because a newly saved record returns an empty hash in #changes meaning checks such as `state_changed? || confidential_changed?` would return false for new rows, thus never updating the counters. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/38061
-
由 Andrew Newdigate 提交于
-
- 06 9月, 2017 3 次提交
-
-
由 micael.bergeron 提交于
also fix some code styling issues
-
由 micael.bergeron 提交于
- only show in merge-requests - show as a little glyph
-
由 Sean McGivern 提交于
-
- 01 9月, 2017 1 次提交
-
-
由 Felipe Artur 提交于
-
- 31 8月, 2017 1 次提交
-
-
由 Jacob Vosmaer 提交于
-
- 30 8月, 2017 1 次提交
-
-
由 Yorick Peterse 提交于
This ensures the issues/MR cache of the sidebar is only updated when the state or confidential flags changes, instead of changing this for every update.
-