An error occurred fetching the project authors.
- 20 Jun, 2018 1 commit
-
-
Mark Chao authored
There is still the edge case when 'no commits' changes to 'conflict' would not trigger notification, which we ignore for now. Calling can_be_merged? can cause exception (e.g. non-UTF8) Ignore those by rescueing. Remove unmergeable_reason as now only conflict is notified Update spec
-
- 05 Jun, 2018 1 commit
-
-
Jacob Vosmaer (GitLab) authored
-
- 01 Jun, 2018 1 commit
-
-
Mark Chao authored
"Maintainer" will be freed to be used for #42751
-
- 29 May, 2018 1 commit
-
-
blackst0ne authored
-
- 24 May, 2018 1 commit
-
-
Mark Chao authored
-
- 17 May, 2018 2 commits
-
-
lulalala authored
For notifying via todo or email.
-
lulalala authored
First, transitions between can_be_merged & cannot_be_merged are removed, as they are currently blocked in `check_if_can_be_merged`. `can_be_merge` always returns to `unchecked` first, before it can transition to `cannot_be_merged` (and vice versa). We want to avoid repeated notification triggered by repeated transition between `cannot_be_merged` & `unchecked`. So we added `cannot_be_merged_recheck` state, similar to `unchecked`, but as a mean to remember it’s from cannot_be_merged. See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18042/#note_65945407 Since `unchecked` and `cannot_be_merged_recheck` both mean “we are in the middle of checking if it is mergeable”, quite often we need to see if merge_status is in either one of them, so `check_state?` is added to achieve this.
-
- 14 May, 2018 1 commit
-
-
Shinya Maeda authored
-
- 07 May, 2018 1 commit
-
-
Oswaldo Ferreira authored
-
- 03 May, 2018 1 commit
-
-
blackst0ne authored
-
- 20 Apr, 2018 1 commit
-
-
Andreas Brandl authored
-
- 16 Apr, 2018 1 commit
-
-
Clement Ho authored
-
- 13 Apr, 2018 1 commit
-
-
Clement Ho authored
-
- 21 Mar, 2018 1 commit
-
-
Sean McGivern authored
Previously, this would issue a query for each unique `diff_refs_or_sha` passed. This was because we didn't want to load other MR diffs into memory, as they had some very large columns. Now they are actually very small, and it's more efficient to just load them all at once and do the finding in Ruby.
-
- 16 Mar, 2018 1 commit
-
-
Andreas Brandl authored
-
- 15 Mar, 2018 1 commit
-
-
Sean McGivern authored
Previously, we kept them all in the cache. We don't need the highlight results for older diffs - if someone does view that (which is rare), we can do the highlighting on the fly.
-
- 07 Mar, 2018 1 commit
-
-
Bob Van Landuyt authored
When a project is not private, and the source branch not protected the user can now select the option to allow maintainers to push to this branch
-
- 30 Jan, 2018 1 commit
-
-
Oswaldo Ferreira authored
-
- 29 Jan, 2018 2 commits
-
-
Oswaldo Ferreira authored
-
Sean McGivern authored
-
- 25 Jan, 2018 1 commit
-
-
Nick Thomas authored
On MySQL, at least, `Note#created_at` doesn't seem to store fractional seconds, while `MergeRequest::Metrics#merged_at` does. This breaks the optimization assumption that we only need to search for notes created *after* the MR has been merged. Unsynchronized system clocks also make this a dangerous assumption to make. Adding a minute of leeway still optimizes away most notes, but allows both cases to be handled more gracefully. If the system clocks are more than a minute out, we'll still be broken, of course.
-
- 24 Jan, 2018 1 commit
-
-
Oswaldo Ferreira authored
-
- 23 Jan, 2018 1 commit
-
-
Oswaldo Ferreira authored
-
- 12 Jan, 2018 2 commits
-
-
Hiroyuki Sato authored
-
Sean McGivern authored
If we search for notes before the MR was merged, we have to load every commit that was ever part of the MR, or mentioned in a push. In extreme cases, this can be tens of thousands of commits to load, but we know they can't revert the merge commit, because they are from before the MR was merged. In the (rare) case that we don't have a `merged_at` value for the MR, we can still search all notes.
-
- 10 Jan, 2018 1 commit
-
-
Ahmad Sherif authored
Closes gitaly#866
-
- 08 Jan, 2018 1 commit
-
-
Yorick Peterse authored
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 Jan, 2018 1 commit
-
-
Jan Provaznik authored
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
-
- 02 Jan, 2018 1 commit
-
-
Oswaldo Ferreira authored
-
- 22 Dec, 2017 1 commit
-
-
blackst0ne authored
-
- 14 Dec, 2017 1 commit
-
-
Zeger-Jan van de Weg authored
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 Dec, 2017 1 commit
-
-
Felipe Artur authored
-
- 12 Dec, 2017 1 commit
-
-
Zeger-Jan van de Weg authored
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 Dec, 2017 1 commit
-
-
micael.bergeron authored
-
- 06 Dec, 2017 1 commit
-
-
Yorick Peterse authored
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 Dec, 2017 4 commits
-
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
Jarka Kadlecova authored
-
- 28 Nov, 2017 1 commit
-
-
Sean McGivern authored
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.
-