An error occurred fetching the project authors.
  1. 20 Jun, 2018 1 commit
    • Mark Chao's avatar
      Notify only when unmergeable due to conflict · 5b994b81
      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
      5b994b81
  2. 05 Jun, 2018 1 commit
  3. 01 Jun, 2018 1 commit
  4. 29 May, 2018 1 commit
  5. 24 May, 2018 1 commit
  6. 17 May, 2018 2 commits
    • lulalala's avatar
      Add MergeRequest#merge_participants · 179a1ee7
      lulalala authored
      For notifying via todo or email.
      179a1ee7
    • lulalala's avatar
      Add cannot_be_merged_recheck merge_status · 75171053
      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.
      75171053
  7. 14 May, 2018 1 commit
  8. 07 May, 2018 1 commit
  9. 03 May, 2018 1 commit
  10. 20 Apr, 2018 1 commit
  11. 16 Apr, 2018 1 commit
  12. 13 Apr, 2018 1 commit
  13. 21 Mar, 2018 1 commit
    • Sean McGivern's avatar
      Fix N+1 in `MergeRequest#merge_request_diff_for` · 39c9928c
      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.
      39c9928c
  14. 16 Mar, 2018 1 commit
  15. 15 Mar, 2018 1 commit
  16. 07 Mar, 2018 1 commit
  17. 30 Jan, 2018 1 commit
  18. 29 Jan, 2018 2 commits
  19. 25 Jan, 2018 1 commit
    • Nick Thomas's avatar
      Look at notes created just before merge when deciding if an MR can be reverted · b02f9b61
      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.
      b02f9b61
  20. 24 Jan, 2018 1 commit
  21. 23 Jan, 2018 1 commit
  22. 12 Jan, 2018 2 commits
  23. 10 Jan, 2018 1 commit
  24. 08 Jan, 2018 1 commit
  25. 05 Jan, 2018 1 commit
    • Jan Provaznik's avatar
      Backport 'Rebase' feature from EE to CE · 27a75ea1
      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
      27a75ea1
  26. 02 Jan, 2018 1 commit
  27. 22 Dec, 2017 1 commit
  28. 14 Dec, 2017 1 commit
    • Zeger-Jan van de Weg's avatar
      Clear caches before updating MR diffs · 8ad41255
      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.
      8ad41255
  29. 13 Dec, 2017 1 commit
  30. 12 Dec, 2017 1 commit
    • Zeger-Jan van de Weg's avatar
      Use memoization for commits on diffs · 3ab026b7
      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
      3ab026b7
  31. 07 Dec, 2017 1 commit
  32. 06 Dec, 2017 1 commit
    • Yorick Peterse's avatar
      Throttle the number of UPDATEs triggered by touch · 856447cc
      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.
      856447cc
  33. 05 Dec, 2017 4 commits
  34. 28 Nov, 2017 1 commit
    • Sean McGivern's avatar
      Ensure MRs always use branch refs for comparison · 3c6a4d63
      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.
      3c6a4d63