Read about our upcoming Code of Conduct on this issue

  1. 16 May, 2016 6 commits
    • Robert Speicher's avatar
    • Robert Speicher's avatar
      Rename `Event#note_commit?` to `commit_note?` · b4171aba3ca8
      Robert Speicher authored
    • Robert Speicher's avatar
      Simplify Event's target type-checking · ebd49bbf7199
      Robert Speicher authored
    • Robert Speicher's avatar
      Add an Event's target's title to its reference link · 7f5253bd668c
      Robert Speicher authored
      Given an activity feed entry like:
      > Douwe Maan commented on [issue #123] at [gitlab-org/gitlab-ce]
      ...the `issue #123` link will now have a `title` attribute.
    • Sean McGivern's avatar
      Return a relation with Postgres · 98ea3a9253c8
      Sean McGivern authored
      Postgres only needs to select a single column, so that can used as a
      sub-query where `Milestone.upcoming_ids_by_projects` is actually used in
      MySQL needs to select the `due_date` column because it's used in the
      `HAVING` clause, so it has to return an array of IDs.
    • Sean McGivern's avatar
      Make upcoming milestone work across projects · 6dcb77744929
      Sean McGivern authored
      Before: we took the next milestone due across all projects in the
      search and found issues whose milestone title matched that
      one. Problems:
      1. The milestone could be closed.
      2. Different projects have milestones with different schedules.
      3. Different projects have milestones with different titles.
      4. Different projects can have milestones with different schedules, but
         the _same_ title. That means we could show issues from a past
         milestone, or one that's far in the future.
      After: gather the ID of the next milestone on each project we're looking
      at, and find issues with those milestone IDs. Problems:
      1. For a lot of projects, this can return a lot of IDs.
      2. The SQL query has to be different between Postgres and MySQL, because
         MySQL is much more lenient with HAVING: as well as the columns
         appearing in GROUP BY or in aggregate clauses, MySQL allows them to
         appear in the SELECT list (un-aggregated).
  2. 14 May, 2016 2 commits
  3. 13 May, 2016 5 commits
  4. 12 May, 2016 7 commits
  5. 11 May, 2016 3 commits
  6. 10 May, 2016 7 commits
  7. 09 May, 2016 7 commits
  8. 08 May, 2016 2 commits
  9. 07 May, 2016 1 commit