BigW Consortium Gitlab

  1. 11 Oct, 2016 1 commit
  2. 02 Aug, 2016 1 commit
  3. 27 Jul, 2016 1 commit
  4. 26 Jul, 2016 1 commit
  5. 21 Jun, 2016 1 commit
    • Optimize Banzai::Filter::RelativeLinkFilter · ca696175
      Alejandro Rodríguez authored
          A lot of git operations were being repeated, for example, to build a url
          you would ask if the path was a Tree, which would call a recursive routine
          in Gitlab::Git::Tree#where, then ask if the path was a Blob, which would
          call a recursive routine at Gitlab::Git::Blob#find, making reference to
          the same git objects several times. Now we call Rugged::Tree#path, which
          allows us to determine the type of the path in one pass.
      
          Some other minor improvement added, like saving commonly used references
          instead of calculating them each time.
  6. 03 Jun, 2016 2 commits
  7. 01 Jun, 2016 1 commit
    • 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.
  8. 13 May, 2016 1 commit
  9. 16 Apr, 2016 1 commit
  10. 17 Mar, 2016 1 commit
  11. 22 Feb, 2016 1 commit
  12. 09 Dec, 2015 1 commit
  13. 07 Dec, 2015 2 commits
  14. 04 Dec, 2015 1 commit
  15. 01 Dec, 2015 1 commit
  16. 30 Nov, 2015 1 commit
  17. 12 Oct, 2015 1 commit
  18. 22 Jun, 2015 1 commit
  19. 26 May, 2015 1 commit
  20. 24 Apr, 2015 2 commits
  21. 16 Apr, 2015 2 commits
  22. 14 Apr, 2015 1 commit
  23. 12 Feb, 2015 1 commit
  24. 20 Jan, 2015 1 commit
  25. 10 Oct, 2014 2 commits
  26. 03 Oct, 2014 1 commit
  27. 01 Aug, 2014 1 commit
  28. 22 Jan, 2014 1 commit
  29. 25 Aug, 2013 1 commit
    • Link issues from comments and automatically close them · c8a115c0
      ash wilson authored
      Any mention of Issues, MergeRequests, or Commits via GitLab-flavored markdown
      references in descriptions, titles, or attached Notes creates a back-reference
      Note that links to the original referencer. Furthermore, pushing commits with
      commit messages that match a (configurable) regexp to a project's default
      branch will close any issues mentioned by GFM in the matched closing phrase.
      If accepting a merge request would close any Issues in this way, a banner is
      appended to the merge request's main panel to indicate this.
  30. 13 Aug, 2013 1 commit
  31. 18 Jul, 2013 1 commit
    • Merge Request on forked projects · 3d7194f0
      Izaak Alpert authored
      The good:
      
       - You can do a merge request for a forked commit and it will merge properly (i.e. it does work).
       - Push events take into account merge requests on forked projects
       - Tests around merge_actions now present, spinach, and other rspec tests
       - Satellites now clean themselves up rather then recreate
      
      The questionable:
      
       - Events only know about target projects
       - Project's merge requests only hold on to MR's where they are the target
       - All operations performed in the satellite
      
      The bad:
      
        -  Duplication between project's repositories and satellites (e.g. commits_between)
      
      (for reference: http://feedback.gitlab.com/forums/176466-general/suggestions/3456722-merge-requests-between-projects-repos)
      
      Fixes:
      
      Make test repos/satellites only create when needed
      -Spinach/Rspec now only initialize test directory, and setup stubs (things that are relatively cheap)
      -project_with_code, source_project_with_code, and target_project_with_code now create/destroy their repos individually
      -fixed remote removal
      -How to merge renders properly
      -Update emails to show project/branches
      -Edit MR doesn't set target branch
      -Fix some failures on editing/creating merge requests, added a test
      -Added back a test around merge request observer
      -Clean up project_transfer_spec, Remove duplicate enable/disable observers
      -Ensure satellite lock files are cleaned up, Attempted to add some testing around these as well
      -Signifant speed ups for tests
      -Update formatting ordering in notes_on_merge_requests
      -Remove wiki schema update
      Fixes for search/search results
      -Search results was using by_project for a list of projects, updated this to use in_projects
      -updated search results to reference the correct (target) project
      -udpated search results to print both sides of the merge request
      
      Change-Id: I19407990a0950945cc95d62089cbcc6262dab1a8
  32. 03 Apr, 2013 1 commit
  33. 01 Apr, 2013 2 commits
  34. 31 Mar, 2013 1 commit