- 05 1月, 2018 1 次提交
-
-
由 Jan Provaznik 提交于
When a project uses fast-forward merging strategy user has to rebase MRs to target branch before it can be merged. Now user can do rebase in UI by clicking 'Rebase' button instead of doing rebase locally. This feature was already present in EE, this is only backport of the feature to CE. Couple of changes: * removed rebase license check * renamed migration (changed timestamp) Closes #40301
-
- 03 1月, 2018 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 22 12月, 2017 1 次提交
-
-
由 blackst0ne 提交于
-
- 14 12月, 2017 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
The hook ordering influenced the diffs being generated as these used values from before the update due to the memoization still being in place. This commit reorders them and tests against this behaviour.
-
- 13 12月, 2017 1 次提交
-
-
由 Felipe Artur 提交于
-
- 12 12月, 2017 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
The Gitaly CommitService is being hammered by n + 1 calls, mostly when finding commits. This leads to this gRPC being turned of on production: https://gitlab.com/gitlab-org/gitaly/issues/514#note_48991378 Hunting down where it came from, most of them were due to MergeRequest#show. To prove this, I set a script to request the MergeRequest#show page 50 times. The GDK was being scraped by Prometheus, where we have metrics on controller#action and their Gitaly calls performed. On both occations I've restarted the full GDK so all caches had to be rebuild. Current master, 806a68a8, needed 435 requests After this commit, 154 requests
-
- 07 12月, 2017 1 次提交
-
-
由 micael.bergeron 提交于
-
- 06 12月, 2017 1 次提交
-
-
由 Yorick Peterse 提交于
This throttles the number of UPDATE queries that can be triggered by calling "touch" on a Note, Issue, or MergeRequest. For Note objects we also take care of updating the associated "noteable" relation in a smarter way than Rails does by default.
-
- 05 12月, 2017 4 次提交
-
-
由 Felipe Artur 提交于
-
由 Felipe Artur 提交于
-
由 Felipe Artur 提交于
-
由 Jarka Kadlecova 提交于
-
- 29 11月, 2017 1 次提交
-
-
由 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.
-
- 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 提交于
-
- 06 11月, 2017 1 次提交
-
-
由 micael.bergeron 提交于
-
- 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!
-
- 28 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 27 10月, 2017 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
Now, when requesting a commit from the Repository model, the results are not cached. This means we're fetching the same commit by oid multiple times during the same request. To prevent us from doing this, we now cache results. Caching is done only based on object id (aka SHA). Given we cache on the Repository model, results are scoped to the associated project, eventhough the change of two repositories having the same oids for different commits is small.
-
- 13 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 12 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 09 10月, 2017 2 次提交
-
-
由 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 提交于
The helper creates a fork of a project with all provided attributes, but skipping the creation of the repository on disk.
-
由 Bob Van Landuyt 提交于
-
- 04 10月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 06 9月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
-
- 01 9月, 2017 1 次提交
-
-
由 Felipe Artur 提交于
-
- 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.
-
- 29 8月, 2017 2 次提交
-
-
由 Oswaldo Ferreira 提交于
-
由 Oswaldo Ferreira 提交于
-
- 23 8月, 2017 1 次提交
-
-
由 Yorick Peterse 提交于
Every project page displays a navigation menu that in turn displays the number of open issues and merge requests. This means that for every project page we run two COUNT(*) queries, each taking up roughly 30 milliseconds on GitLab.com. By caching these numbers and refreshing them whenever necessary we can reduce loading times of all these pages by up to roughly 60 milliseconds. The number of open issues does not include confidential issues. This is a trade-off to keep the code simple and to ensure refreshing the data only needs 2 COUNT(*) queries instead of 3. A downside is that if a project only has 5 confidential issues the counter will be set to 0. Because we now have 3 similar counting service classes the code previously used in Projects::ForksCountService has mostly been moved to Projects::CountService, which in turn is reused by the various service classes. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36622
-
- 13 8月, 2017 1 次提交
-
-
由 haseeb 提交于
-
- 11 8月, 2017 1 次提交
-
-
由 Robert Speicher 提交于
-
- 09 8月, 2017 1 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 08 8月, 2017 1 次提交
-
-
由 Oswaldo Ferreira 提交于
-
- 03 8月, 2017 1 次提交
-
-
由 Robert Speicher 提交于
-
- 01 8月, 2017 1 次提交
-
-
由 Gabriel Mazetto 提交于
-
- 27 7月, 2017 1 次提交
-
-
由 Rémy Coutable 提交于
Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true Signed-off-by: NRémy Coutable <remy@rymai.me>
-