1. 07 Mar, 2016 1 commit
  2. 23 Feb, 2016 1 commit
  3. 17 Feb, 2016 1 commit
  4. 15 Feb, 2016 1 commit
  5. 12 Feb, 2016 1 commit
  6. 11 Feb, 2016 1 commit
  7. 09 Feb, 2016 1 commit
    • Yorick Peterse's avatar
      Smarter flushing of branch statistics caches · d9a8480275aa
      Yorick Peterse authored
      Instead of flushing the behind/ahead counts for all branches upon every
      push we now only flush the cache of branches that actually need to have
      these statistics recalculated. There are now basically 2 scenarios and
      their effects:
      
      1. A user pushes a commit to the default branch, this results in the
         cache being flushed for all branches.
      2. A user pushes to a non default branch, this results in _only_ the
         cache for that branch being flushed.
      
      The existing code (Repository#expire_cache) remains backwards compatible
      with the previous behaviour, the new behaviour is only applied when a
      branch name is passed as an argument. This ensures that when for example
      a project is deleted the cache for all branches is flushed.
      d9a8480275aa
  8. 08 Feb, 2016 1 commit
    • Yorick Peterse's avatar
      Cache various Repository Git operations · 09d8684679a2
      Yorick Peterse authored
      This caches the output of the following methods:
      
      * Repository#empty?
      * Repository#has_visible_content?
      * Repository#root_ref
      
      The cache for Repository#has_visible_content? is flushed whenever a
      commit is pushed to a new branch or an existing branch is removed.
      The cache for Repository#root_ref is only flushed whenever a user
      changes the default branch of a project. The cache for Repository#empty?
      is never explicitly flushed as there's no need for it.
      09d8684679a2
  9. 11 Dec, 2015 1 commit
  10. 19 Nov, 2015 1 commit
  11. 13 Nov, 2015 1 commit
  12. 18 Oct, 2015 1 commit
  13. 16 Oct, 2015 1 commit
    • Stan Hu's avatar
      Add a system note and update relevant merge requests when a branch is deleted or re-added · 756991a25da7
      Stan Hu authored
      If a branch is deleted with an open merge request, amended offline, and then pushed again,
      GitLab doesn't bother to update the merge request even though the last commit ID and/or
      code may have changed. This MR ensures that each push will update any relevant merge
      requests and adds a system note if this happens as well.
      
      Closes #2926
      756991a25da7
  14. 12 Oct, 2015 1 commit
  15. 02 Oct, 2015 1 commit
  16. 23 Sep, 2015 2 commits
  17. 22 Aug, 2015 1 commit
  18. 11 Aug, 2015 3 commits
  19. 17 Jul, 2015 2 commits
  20. 15 Jul, 2015 1 commit
  21. 22 Jun, 2015 1 commit
  22. 12 Jun, 2015 1 commit
  23. 02 Jun, 2015 1 commit
  24. 06 May, 2015 1 commit
  25. 24 Apr, 2015 2 commits
  26. 02 Apr, 2015 2 commits
  27. 21 Mar, 2015 1 commit
  28. 19 Mar, 2015 1 commit
  29. 13 Mar, 2015 3 commits
  30. 10 Mar, 2015 1 commit
  31. 09 Mar, 2015 1 commit
    • Hannes Rosenögger's avatar
      fix mass SQL statements on initial push · fa26853876b5
      Hannes Rosenögger authored
      This commit disables process_commit_messages()
      for the initial push to the default branch.
      This fixes the mass SQL statements (~500000) that were executed during
      the initial push of the linux kernel for example.
      fa26853876b5
  32. 03 Mar, 2015 1 commit
    • Stan Hu's avatar
      Issue #595: Support Slack notifications upon issue and merge request events · 2fc13aea08b1
      Stan Hu authored
      1) Adds a DB migration for all services to toggle on push, issue, and merge events.
      
      2) Upon an issue or merge request event, fire service hooks.
      
      3) Slack service supports custom messages for each of these events. Other services
      not supported at the moment.
      
      4) Label merge request hooks with their corresponding actions.
      2fc13aea08b1