1. 17 Mar, 2016 1 commit
  2. 12 Jan, 2016 3 commits
  3. 11 Jan, 2016 11 commits
  4. 10 Jan, 2016 2 commits
  5. 08 Jan, 2016 1 commit
    • Stan Hu's avatar
      Merge branch 'suppress-allow-failure-builds' into 'master' · 34d0f226
      Stan Hu authored
      Suppress e-mails on failed builds if allow_failure is set
      
      Every time I push to GitLab, I get > 2 emails saying a spec failed when I don't care about the benchmarks and others that have `allow_failure` set to `true`.
      
      @ayufan mentioned creating a summary e-mail to prevent getting one e-mail per build, but the latter might actually be desirable. For example, I do want to know if Rubocop errors fail right away.
      
      See merge request !2178
      34d0f226
  6. 06 Jan, 2016 2 commits
    • Robert Speicher's avatar
      Merge branch 'merge-when-build-succeeds-unchecked' into 'master' · f076e4eb
      Robert Speicher authored
      Get "Merge when build succeeds" to work when commits were pushed to MR
      target branch while builds were running
      
      The Merge when build succeeds service only merges when the MR is
      mergeable (open, not WIP, no conflicts).
      
      When the target branch is updated, all affected MRs have their merge
      status set to `unchecked`, and the conflicts check will only happen
      when `check_if_can_be_merged` is called, which happens when the MR page
      is viewed.
      
      When someone enables the automatic merge, the target branch is updated,
      no-one views the MR page again, and the build succeeds, the mergeability
      check will fail and the MR will not in fact be merged.
      
      This MR makes sure `check_if_can_be_merged` is always called when MR
      mergeability is checked.
      
      See merge request !2304
      f076e4eb
    • Robert Speicher's avatar
      Revert "Merge branch 'debug-banzai-cache' into 'master'" · be19feca
      Robert Speicher authored
      This reverts commit 9c8ce4b6.
      be19feca
  7. 05 Jan, 2016 1 commit
  8. 04 Jan, 2016 3 commits
  9. 31 Dec, 2015 2 commits
  10. 30 Dec, 2015 4 commits
  11. 29 Dec, 2015 7 commits
    • Robert Speicher's avatar
      Update CHANGELOG · 1211734e
      Robert Speicher authored
      [ci skip]
      1211734e
    • Marin Jankovski's avatar
      Version 8.3.2 · fbb8b6e6
      Marin Jankovski authored
      fbb8b6e6
    • Marin Jankovski's avatar
      Merge branch 'recaptcha_to_stable' into '8-3-stable' · 450ea191
      Marin Jankovski authored
      Recaptcha to stable
      
      
      
      See merge request !2236
      450ea191
    • Stan Hu's avatar
    • Gabriel Mazetto's avatar
    • Dmitriy Zaporozhets's avatar
      Merge branch 'add-recaptcha-support' into 'master' · 2ef0feca
      Dmitriy Zaporozhets authored
      Add support for Google reCAPTCHA in user registration to prevent spammers
      
      See merge request !2216
      2ef0feca
    • Dmitriy Zaporozhets's avatar
      Merge branch 'disable-git-follow' into 'master' · 795a29ae
      Dmitriy Zaporozhets authored
      Disable --follow in `git log` to avoid loading duplicate commit data in infinite scroll
      
      `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](https://github.com/git/git/blob/master/revision.c#L2351).
      * If the `prune` flag is active, `get_commit_action()` determines whether the commit should be [scanned for matching paths](https://github.com/git/git/blob/master/revision.c#L2989).
      * In the case of `--follow`, however, `prune` is [disabled here](https://github.com/git/git/blob/master/revision.c#L2350).
      * 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 a every other entry 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
      
      See merge request !2210
      795a29ae
  12. 28 Dec, 2015 1 commit
  13. 24 Dec, 2015 2 commits