1. 16 Mar, 2018 1 commit
  2. 15 Mar, 2018 1 commit
  3. 07 Mar, 2018 1 commit
  4. 30 Jan, 2018 1 commit
  5. 29 Jan, 2018 2 commits
  6. 25 Jan, 2018 1 commit
    • Nick Thomas's avatar
      Look at notes created just before merge when deciding if an MR can be reverted · d5a7ab226edf
      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.
  7. 24 Jan, 2018 1 commit
  8. 23 Jan, 2018 1 commit
  9. 12 Jan, 2018 2 commits
  10. 10 Jan, 2018 1 commit
  11. 08 Jan, 2018 1 commit
  12. 05 Jan, 2018 1 commit
    • Jan Provaznik's avatar
      Backport 'Rebase' feature from EE to CE · 3b76393647fc
      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
  13. 02 Jan, 2018 1 commit
  14. 22 Dec, 2017 1 commit
  15. 14 Dec, 2017 1 commit
    • Zeger-Jan van de Weg's avatar
      Clear caches before updating MR diffs · 484622e80519
      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.
  16. 13 Dec, 2017 1 commit
  17. 12 Dec, 2017 1 commit
    • Zeger-Jan van de Weg's avatar
      Use memoization for commits on diffs · 72ad6dff79a5
      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:
      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, 806a68a81f1baee, needed 435 requests
      After this commit, 154 requests
  18. 07 Dec, 2017 1 commit
  19. 06 Dec, 2017 1 commit
    • Yorick Peterse's avatar
      Throttle the number of UPDATEs triggered by touch · 4e971949a7d4
      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.
  20. 05 Dec, 2017 4 commits
  21. 28 Nov, 2017 1 commit
    • Sean McGivern's avatar
      Ensure MRs always use branch refs for comparison · 0abebd33c0b3
      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
  22. 23 Nov, 2017 1 commit
    • Sean McGivern's avatar
      Use latest_merge_request_diff association · 8f7f03910539
      Sean McGivern authored
      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
      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.
  23. 13 Nov, 2017 1 commit
  24. 11 Nov, 2017 1 commit
  25. 06 Nov, 2017 1 commit
  26. 03 Nov, 2017 1 commit
    • micael.bergeron's avatar
      removed the #ensure_ref_fetched from all controllers · 680c4465158f
      micael.bergeron authored
      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!
  27. 27 Oct, 2017 2 commits
    • Oswaldo Ferreira's avatar
    • Zeger-Jan van de Weg's avatar
      Cache commits on the repository model · 77de64bc4589
      Zeger-Jan van de Weg authored
      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.
  28. 13 Oct, 2017 1 commit
  29. 11 Oct, 2017 1 commit
  30. 09 Oct, 2017 2 commits
  31. 07 Oct, 2017 2 commits
  32. 04 Oct, 2017 1 commit