An error occurred fetching the project authors.
  1. 02 Aug, 2016 1 commit
    • Paco Guzman's avatar
      Speedup DiffNote#active? on discussions, preloading noteables and avoid... · 8716ff7f
      Paco Guzman authored
      Speedup DiffNote#active? on discussions, preloading noteables and avoid touching git repository to return diff_refs when possible
      
      - Preloading noteable we share the same noteable instance when more than one 
      discussion refers to the same noteable.
      - Any other call to that object that is cached in that object will be for any 
      discussion.
      - In those cases where merge_request_diff has all the sha stored to build a diff_refs get that 
      diff_refs using directly those sha instead accessing to the git repository to first get the 
      commits and later the sha.
      8716ff7f
  2. 31 Jul, 2016 1 commit
    • Douglas Barbosa Alexandre's avatar
      Fix attr reader to force the intended values for source and target shas · 5b4ceeed
      Douglas Barbosa Alexandre authored
      When importing a pull request from GitHub, the old and new branches may
      no longer actually exist by those names, but we need to recreate the
      merge request diff with the right source and target shas.
      
      We use these `target_branch_sha` and `source_branch_sha` attributes to
      force these to the intended values. But the reader methods were always
      looking up to the target/source branch head instead of check if these
      values was previously set.
      5b4ceeed
  3. 08 Jul, 2016 1 commit
    • Sean McGivern's avatar
      Collapse large diffs by default · b6b26692
      Sean McGivern authored
      When rendering a list of diff files, skip those where the diff is over
      10 KB and provide an endpoint to render individually instead.
      b6b26692
  4. 06 Jul, 2016 2 commits
  5. 04 Jul, 2016 1 commit
  6. 10 Jun, 2016 4 commits
  7. 03 Jun, 2016 4 commits
  8. 02 Jun, 2016 2 commits
  9. 01 Jun, 2016 1 commit
    • Yorick Peterse's avatar
      Refactor Participable · 580d2501
      Yorick Peterse authored
      There are several changes to this module:
      
      1. The use of an explicit stack in Participable#participants
      2. Proc behaviour has been changed
      3. Batch permissions checking
      
      == Explicit Stack
      
      Participable#participants no longer uses recursion to process "self" and
      all child objects, instead it uses an Array and processes objects in
      breadth-first order. This allows us to for example create a single
      Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
      a ReferenceExtractor removes the need for running potentially many SQL
      queries every time a Proc is called on a new object.
      
      == Proc Behaviour Changed
      
      Previously a Proc in Participable was expected to return an Array of
      User instances. This has been changed and instead it's now expected that
      a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
      value of the Proc is ignored.
      
      == Permissions Checking
      
      The method Participable#participants uses
      Ability.users_that_can_read_project to check if the returned users have
      access to the project of "self" _without_ running multiple SQL queries
      for every user.
      580d2501
  10. 29 May, 2016 2 commits
  11. 20 May, 2016 1 commit
  12. 13 May, 2016 1 commit
  13. 09 May, 2016 1 commit
  14. 11 Apr, 2016 1 commit
  15. 29 Mar, 2016 1 commit
  16. 19 Mar, 2016 1 commit
  17. 18 Mar, 2016 2 commits
  18. 17 Mar, 2016 1 commit
  19. 16 Mar, 2016 2 commits
    • Pierre de La Morinerie's avatar
      Fix MergeRequest#source_sha when there is no diff · 18295585
      Pierre de La Morinerie authored
      `MergeRequest#source_sha` is expected to return the sha of the source
      branch last commit.
      
      But when a open Merge Request has no diff (e.g. all commits have already
      been merged to the target branch), `merge_request.source_sha`
      incorrectly returns `nil`.
      
      This was un-noticed before – but now that !2217 has been merged,
      it makes `Gitlab::Git::Commit.between` raise an
      "Unexpected nil argument" exception.
      
      This fixes the crash, by making sure that `source_sha` returns a
      correct result even when there is no diff available.
      18295585
    • Pierre de La Morinerie's avatar
      7cbf8fd0
  20. 11 Mar, 2016 1 commit
    • Yorick Peterse's avatar
      Use a UNION in MergeRequest.in_projects · 4f3fa519
      Yorick Peterse authored
      The OR condition for source_project_id/target_project_id leads to a
      query plan that performs rather poorly on PostgreSQL due to the use of
      sub-queries. Because Rails offers no easy alternative for this
      particular problem we're forced to using a UNION for both conditions.
      The resulting query performs much faster than just using an OR.
      4f3fa519
  21. 03 Mar, 2016 1 commit
  22. 19 Feb, 2016 1 commit
  23. 11 Feb, 2016 1 commit
    • Kirill Zaitsev's avatar
      Add new data to project in push, issue, merge-request and note webhooks data · b123171d
      Kirill Zaitsev authored
      - Add `avatar_url`, `description`, `git_ssh_url`, `git_http_url`,
        `path_with_namespace` and `default_branch` in `project` in push, issue,
        merge-request and note webhooks data
      - Deprecate the `ssh_url` in favor of `git_ssh_url` and `http_url` in
        favor of `git_http_url` in `project` for push, issue, merge-request and
        note webhooks data
      - Deprecate the `repository` key in push, issue, merge-request and
        note webhooks data, use `project` instead
      b123171d
  24. 04 Feb, 2016 1 commit
  25. 01 Feb, 2016 1 commit
    • Yorick Peterse's avatar
      Optimize fetching issues closed by a merge request · 99492d6b
      Yorick Peterse authored
      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
      99492d6b
  26. 06 Jan, 2016 2 commits
  27. 18 Dec, 2015 1 commit
  28. 09 Dec, 2015 1 commit