- 11 2月, 2016 1 次提交
-
-
由 Nemanja Boric 提交于
In case merge request is broken, we shouldn't check if the sha is mergable, as it will be null, and there's no point, as we know that it's not mergable.
-
- 10 2月, 2016 1 次提交
-
-
- 04 2月, 2016 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
Fixes #3339 This MR hides the 'Remove source branch' button when a new commit is added to the source branch
-
- 01 2月, 2016 1 次提交
-
-
由 Yorick Peterse 提交于
Instead of running ClosingIssueExtractor for every commit in a merge request we can gather all the commit messages (and the merge request description), concatenate all this together and then run ClosingIssueExtractor only once. The result of this is that MergeRequest#closes_issues is now between 3.5x and 4x faster than the old setup. Using a merge request with 10 commits (each referencing a number of issues to close) this reduced the call duration from around 200 milliseconds to around 50 milliseconds. As a result of these changes the Jira related tests for MergeRequest#closes_issues have been removed. These tests stubbed Commit#closes_issues meaning that the only code that was really tested was the call to Array#uniq to filter out duplicate issues. As this code is no longer used (nor present) the corresponding tests were removed. Related: gitlab-org/gitlab-ce#12419
-
- 28 1月, 2016 2 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 21 1月, 2016 1 次提交
-
-
由 Douwe Maan 提交于
-
- 20 1月, 2016 2 次提交
-
-
由 Douwe Maan 提交于
-
由 Rubén Dávila 提交于
-
- 15 1月, 2016 1 次提交
-
-
由 Rubén Dávila 提交于
* Use commit objects instead of IDs when generating diffs * Use proper references when generating MR's source and target * Update broken specs
-
- 13 1月, 2016 1 次提交
-
-
由 Jacob Schatz 提交于
-
- 07 1月, 2016 2 次提交
-
-
由 Yorick Peterse 提交于
These scopes don't care about the order. Removing the explicit "ORDER BY" can speed up the queries by a little bit.
-
由 Yorick Peterse 提交于
This replaces plucking of IDs with a sub-query, saving the overhead of loading the data in Ruby and then mapping the rows to an Array of IDs. This also scales much better when dealing with a large amount of IDs that would be involved.
-
- 06 1月, 2016 2 次提交
-
-
由 Stan Hu 提交于
-
由 Jacob Schatz 提交于
-
- 05 1月, 2016 1 次提交
-
-
由 Douwe Maan 提交于
Get "Merge when build succeeds" to work when commits were pushed to MR target branch while builds were running
-
- 19 12月, 2015 1 次提交
-
-
由 Drew Blessing 提交于
-
- 15 12月, 2015 1 次提交
-
-
由 Gabriel Mazetto 提交于
-
- 09 12月, 2015 1 次提交
-
-
由 Douwe Maan 提交于
-
- 07 12月, 2015 1 次提交
-
-
由 Valery Sizov 提交于
-
- 05 12月, 2015 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
- 02 12月, 2015 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
- 01 12月, 2015 3 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 24 11月, 2015 1 次提交
-
-
由 Ted Hogan 提交于
Modified changelog
-
- 23 11月, 2015 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
- 21 11月, 2015 1 次提交
-
-
由 Yorick Peterse 提交于
When calling MergeRequest#ci_commit the code would previously raise an error if the source project no longer existed (e.g. because the user removed their fork). See #3599 for more information.
-
- 19 11月, 2015 1 次提交
-
-
由 Yorick Peterse 提交于
When using IssuableFinder/IssuesFinder to find issues for multiple projects it's more efficient to use a JOIN + a "WHERE project_id IN" condition opposed to running a sub-query. This change means that when finding issues without labels we're now using the following SQL: SELECT issues.* FROM issues JOIN projects ON projects.id = issues.project_id LEFT JOIN label_links ON label_links.target_type = 'Issue' AND label_links.target_id = issues.id WHERE ( projects.id IN (...) OR projects.visibility_level IN (20, 10) ) AND issues.state IN ('opened','reopened') AND label_links.id IS NULL ORDER BY issues.id DESC; instead of: SELECT issues.* FROM issues LEFT JOIN label_links ON label_links.target_type = 'Issue' AND label_links.target_id = issues.id WHERE issues.project_id IN ( SELECT id FROM projects WHERE id IN (...) OR visibility_level IN (20,10) ) AND issues.state IN ('opened','reopened') AND label_links.id IS NULL ORDER BY issues.id DESC; The big benefit here is that in the last case PostgreSQL can't properly use all available indexes. In particular it ends up performing a sequence scan on the "label_links" table (processing around 290 000 rows). The new query is roughly 2x as fast as the old query.
-
- 18 11月, 2015 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
- 14 11月, 2015 1 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 13 11月, 2015 1 次提交
-
-
由 Minsik Yoon 提交于
fix this issue(https://gitlab.com/gitlab-org/gitlab-ce/issues/1393). Add ignore whitespace optoin to Commits Compare view
-
- 03 11月, 2015 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
- 23 10月, 2015 2 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
由 Valery Sizov 提交于
-
- 20 10月, 2015 1 次提交
-
-
由 Douwe Maan 提交于
-
- 16 10月, 2015 2 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
由 Zeger-Jan van de Weg 提交于
-
- 09 10月, 2015 1 次提交
-
-
由 Ben Boeckel 提交于
-
- 08 10月, 2015 1 次提交
-
-
由 Ben Boeckel 提交于
-