Read about our upcoming Code of Conduct on this issue

  1. 14 Nov, 2019 1 commit
  2. 08 Nov, 2018 1 commit
  3. 16 Jul, 2018 1 commit
  4. 09 Jul, 2018 1 commit
  5. 19 Sep, 2017 1 commit
  6. 14 Aug, 2017 1 commit
  7. 20 Apr, 2017 1 commit
  8. 03 Mar, 2017 2 commits
  9. 02 Mar, 2017 1 commit
  10. 01 Mar, 2017 1 commit
  11. 23 Feb, 2017 4 commits
  12. 06 Jan, 2017 2 commits
  13. 05 Jan, 2017 3 commits
  14. 13 Dec, 2016 1 commit
  15. 10 Dec, 2016 1 commit
  16. 09 Dec, 2016 1 commit
  17. 08 Dec, 2016 1 commit
  18. 07 Dec, 2016 1 commit
  19. 14 Nov, 2016 2 commits
  20. 02 Nov, 2016 1 commit
    • Kamil Trzcinski's avatar
      Don't execute git hooks if you create branch as part of other change · c6ea72fcc7dc
      Kamil Trzcinski authored
      Currently, our procedure for adding a commit requires us to execute `CreateBranchService` before file creation.
      It's OK, but also we do execute `git hooks` (the `PostReceive` sidekiq job) as part of this process.
      However, this hook is execute before the file is actually committed, so the ref is updated.
      
      Secondly, we do execute a `git hooks` after committing file and updating ref.
      This results in duplicate `PostReceive` jobs, where the first one is completely invalid.
      
      This change makes the branch creation, something that is intermediate step of bigger process (file creation or update, commit cherry pick or revert) to not execute git hooks.
      c6ea72fcc7dc
  21. 15 Sep, 2016 1 commit
  22. 18 Jul, 2016 1 commit
  23. 13 Jul, 2016 2 commits
    • Robert Speicher's avatar
      Revert "Merge branch '18193-developers-can-merge' into 'master' · df7fb9e8d12f
      Robert Speicher authored
      This reverts commit 72baf9a18669, reversing
      changes made to cf491007802b.
      df7fb9e8d12f
    • Timothy Andrew's avatar
      Refactor `Gitlab::GitAccess` · a0fe55c0e0b9
      Timothy Andrew authored
      1. Don't use case statements for dispatch anymore. This leads to a lot
         of duplication, and makes the logic harder to follow.
      
      2. Remove duplicated logic.
      
          - For example, the `can_push_to_branch?` exists, but we also have a
            different way of checking the same condition within `change_access_check`.
      
          - This kind of duplication is removed, and the `can_push_to_branch?`
            method is used in both places.
      
      3. Move checks returning true/false to `UserAccess`.
      
          - All public methods in `GitAccess` now return an instance of
            `GitAccessStatus`. Previously, some methods would return
            true/false as well, which was confusing.
      
          - It makes sense for these kinds of checks to be at the level of a
            user, so the `UserAccess` class was repurposed for this. The prior
            `UserAccess.allowed?` classmethod is converted into an instance
            method.
      
          - All external uses of these checks have been migrated to use the
            `UserAccess` class
      
      4. Move the "change_access_check" into a separate class.
      
          - Create the `GitAccess::ChangeAccessCheck` class to run these
            checks, which are quite substantial.
      
          - `ChangeAccessCheck` returns an instance of `GitAccessStatus` as
            well.
      
      5. Break out the boolean logic in `ChangeAccessCheck` into `if/else`
         chains - this seems more readable.
      
      6. I can understand that this might look like overkill for !4892, but I
         think this is a good opportunity to clean it up.
      
          - http://martinfowler.com/bliki/OpportunisticRefactoring.html
      a0fe55c0e0b9
  24. 05 Jul, 2016 3 commits
  25. 18 Apr, 2016 1 commit
  26. 17 Mar, 2016 1 commit
  27. 02 Mar, 2016 1 commit
  28. 19 Feb, 2016 2 commits