An error occurred fetching the project authors.
  1. 31 May, 2017 2 commits
  2. 29 May, 2017 1 commit
  3. 23 May, 2017 2 commits
  4. 18 May, 2017 1 commit
  5. 12 May, 2017 2 commits
    • Sean McGivern's avatar
      Fix conflict resolution from corrupted upstream · ad2bfeb8
      Sean McGivern authored
      I don't know why this happens exactly, but given an upstream and fork repository
      from a customer, both of which required GC, resolving conflicts would corrupt
      the fork so badly that it couldn't be cloned.
      
      This isn't a perfect fix for that case, because the MR may still need to be
      merged manually, but it does ensure that the repository is at least usable.
      
      My best guess is that when we generate the index for the conflict
      resolution (which we previously did in the target project), we obtain a
      reference to an OID that doesn't exist in the source, even though we already
      fetch the refs from the target into the source.
      
      Explicitly setting the source project as the place to get the merge index from
      seems to prevent repository corruption in this way.
      ad2bfeb8
    • Valery Sizov's avatar
      e2a3a509
  6. 09 May, 2017 1 commit
  7. 08 May, 2017 1 commit
  8. 04 May, 2017 1 commit
  9. 03 May, 2017 1 commit
  10. 26 Apr, 2017 1 commit
  11. 25 Apr, 2017 1 commit
    • Sean McGivern's avatar
      Show correct size when MR diff overflows · a0979c05
      Sean McGivern authored
      The problem is that we often go via a diff object constructed from the diffs
      stored in the DB. Those diffs, by definition, don't overflow, so we don't have
      access to the 'correct' `real_size` - that is stored on the MR diff object
      iself.
      a0979c05
  12. 10 Apr, 2017 1 commit
  13. 08 Apr, 2017 3 commits
  14. 05 Apr, 2017 3 commits
  15. 03 Apr, 2017 2 commits
  16. 22 Mar, 2017 1 commit
  17. 21 Mar, 2017 1 commit
  18. 20 Mar, 2017 1 commit
  19. 14 Mar, 2017 1 commit
  20. 02 Mar, 2017 1 commit
  21. 01 Mar, 2017 1 commit
    • James Lopez's avatar
      Update occurrences of MWBS to MWPS · a0101ebf
      James Lopez authored
       Rename column in the database
       Rename fields related to import/export feature
       Rename API endpoints
       Rename documentation links
       Rename the rest of occurrences in the code
       Replace the images that contain the words "build succeeds" and docs referencing to them
       Make sure pipeline is green and nothing is missing.
      
      updated doc images
      
      renamed only_allow_merge_if_build_succeeds in projects and fixed references
      
      more updates
      
      fix some spec failures
      
      fix rubocop offences
      
      fix v3 api spec
      
      fix MR  specs
      
      fixed issues with partials
      
      fix MR spec
      
      fix alignment
      
      add missing v3 to v4 doc
      
      wip - refactor v3 endpoints
      
      fix specs
      
      fix a few typos
      
      fix project specs
      
      copy entities fully to V3
      
      fix  entity error
      
      more fixes
      
      fix failing specs
      
      fixed missing entities in V3 API
      
      remove comment
      
      updated code based on feedback
      
      typo
      
      fix spec
      a0101ebf
  22. 24 Feb, 2017 1 commit
    • Sean McGivern's avatar
      Only create unmergeable todos once · 2da8bc3d
      Sean McGivern authored
      Previously, we created an unmergeable todo when a merge request:
      
      1. Had merge when pipeline succeeds set.
      2. Became unmergeable.
      
      However, when merge when pipeline succeeds fails due to unmergeability,
      the flag isn't actually removed. And a merge request can become
      unmergeable multiple times, as every time the target branch is updated
      we need to re-check the mergeable status. This means that if the todo
      was marked done, and the MR was checked again, a new todo would be
      created for the same event.
      
      Instead of checking this, we should create the todo from the service
      responsible for merging when the pipeline succeeds. That way the todo is
      guaranteed to only be created when we care about it.
      2da8bc3d
  23. 23 Feb, 2017 6 commits
  24. 14 Feb, 2017 1 commit
  25. 13 Feb, 2017 1 commit
  26. 07 Feb, 2017 1 commit
  27. 06 Feb, 2017 1 commit