Read about our upcoming Code of Conduct on this issue

  1. 04 Jan, 2016 1 commit
  2. 03 Jan, 2016 1 commit
  3. 02 Jan, 2016 3 commits
  4. 01 Jan, 2016 5 commits
  5. 30 Dec, 2015 2 commits
  6. 29 Dec, 2015 5 commits
    • Stan Hu's avatar
      Fix project transfer e-mail sending incorrect paths in e-mail notification · 60492038781c
      Stan Hu authored
      The introduction of ActiveJob and `deliver_now` in fd005b7715f3 caused a race
      condition where the mailer would be invoked before the project was committed
      to the database, causing the transfer e-mail notification to show the old
      path instead of the new one.
      Closes #4670
    • Yorick Peterse's avatar
      Write to InfluxDB directly via UDP · caba9046cc8d
      Yorick Peterse authored
      This removes the need for Sidekiq and any overhead/problems introduced
      by TCP. There are a few things to take into account:
      1. When writing data to InfluxDB you may still get an error if the
         server becomes unavailable during the write. Because of this we're
         catching all exceptions and just ignore them (for now).
      2. Writing via UDP apparently requires the timestamp to be in
         nanoseconds. Without this data either isn't written properly.
      3. Due to the restrictions on UDP buffer sizes we're writing metrics one
         by one, instead of writing all of them at once.
    • Grzegorz Bizon's avatar
      Add hotfix that allows to access build artifacts created before 8.3 · 0cdec5629467
      Grzegorz Bizon authored
      This is a temporary hotfix that allows to access build artifacts created
      before 8.3. See #5257.
      This needs to be changed after migrating CI build files.
      Note that `ArtifactUploader` uses `artifacts_path` to create a storage
      directory before and after parsisting `Ci::Build` instance, before and
      after moving a file to store (save and fetch a file).
    • Valery Sizov's avatar
      note votes methids implementation · f396972827c1
      Valery Sizov authored
    • Stan Hu's avatar
  7. 28 Dec, 2015 11 commits
  8. 27 Dec, 2015 1 commit
  9. 26 Dec, 2015 1 commit
  10. 25 Dec, 2015 6 commits
    • Douwe Maan's avatar
      Add link to twitter docs · e9ec13173677
      Douwe Maan authored
    • Douwe Maan's avatar
      Add more twitter metatags. · fb0e277bc539
      Douwe Maan authored
    • Douwe Maan's avatar
      Add og:site_name · 104004cd6370
      Douwe Maan authored
    • Valery Sizov's avatar
      add sorting of awards · 2bc99a7e18f1
      Valery Sizov authored
    • Valery Sizov's avatar
      revert back vote buttons to issue and MR pages · 619e85df9678
      Valery Sizov authored
    • Stan Hu's avatar
      Disable --follow in `git log` to avoid loading duplicate commit data in infinite scroll · ec573bdc12b9
      Stan Hu authored
      `git` doesn't work properly when `--follow` and `--skip` are specified together. We could even be **omitting commits in the Web log** as a result.
      Here are the gory details. Let's say you ran:
      git log -n=5 --skip=2 README
      This is the working case since it omits `--follow`. This is what happens:
      1. `git` starts at `HEAD` and traverses down the tree until it finds the top-most commit relevant to README.
      2. Once this is found, this commit is returned via `get_revision_1()`.
      3. If the `skip_count` is positive, decrement and repeat step 2. Otherwise go onto step 4.
      4. `show_log()` gets called with that commit.
      5. Repeat step 1 until we have all five entries.
      That's exactly what we want. What happens when you use `--follow`? You have to understand how step 1 is performed:
      * When you specify a pathspec on the command-line (e.g. README), a flag `prune` [gets set here](
      * If the `prune` flag is active, `get_commit_action()` determines whether the commit should be [scanned for matching paths](
      * In the case of `--follow`, however, `prune` is [disabled here](
      * As a result, a commit is never scanned for matching paths and therefore never pruned. `HEAD` will always get returned as the first commit, even if it's not relevant to the README.
      * Making matters worse, the `--skip` in the example above would actually skip every other after `HEAD` N times. If README were changed in these skipped commits, we would actually miss information!
      Since git uses a matching algorithm to determine whether a file was renamed, I
      believe `git` needs to generate a diff of each commit to do this and traverse
      each commit one-by-one to do this. I think that's the rationale for disabling
      the `prune` functionality since you can't just do a simple string comparison.
      Closes #4181, #4229, #3574, #2410
  11. 24 Dec, 2015 4 commits