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

Fix the "Show all" link for the keyboard shortcut modal

18cb430f introduced a typo that made this stop working.

See merge request !2218

Add support for Google reCAPTCHA in user registration to prevent spammers

To do:

- [x] Failing reCAPTCHA test causes all the fields to be lost
- ~~[ ] Improve styling of reCAPTCHA box~~ (not possible)
- ~~[ ] Put settings in `application_settings` (?)~~

![image](/uploads/d38ca89820d3c0066fb8aeb645fd77f0/image.png)

![image](/uploads/6b050749963691b023d076682abcf736/image.png)

Page when you fail CAPTCHA:

![image](/uploads/bc4846f0a5144985bc41dfa75eeab4c1/image.png)


See merge request !2216

Bump brakeman to ~> 3.1.0



See merge request !2219

update-init-script was listed two times. removed one without explanation.

`update-init-script` was listed two times. removed one without explanation.

See merge request !2170

[emoji-picker] Do not show frequently used category when it's empty

I added one condition.

See merge request !2221

Fix intermittent timeout problems with feature specs.

This MR updates the gitlab-ci config to compile assets before running feature specs.

Closes #4662

See merge request !2220

Only allow group/project members to mention `@all`

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/3473

See merge request !2205

Fix typo on triggers docs



See merge request !2214

Remove incomplete text on triggers doc



See merge request !2213

open and close issue via ajax request. With tests

Close and Reopen issues with ajax request.

See merge request !2164

Revert vote buttons back to issue and MR pages

https://gitlab.com/gitlab-org/gitlab-ce/issues/3672



/cc @dzaporozhets @JobV 


![joxi_screenshot_1450809309400](/uploads/379a75505e0d5f24e743aa0a6a6684e2/joxi_screenshot_1450809309400.png)


See merge request !2206

Add Open Graph meta tags



See merge request !2192

Adding  CRIME Vulnerability to Security doc

Added an additional page to the security section that goes over current status and fixes for the TLS Protocol CRIME Vulnerability. Also added its respective link at the security README. 

Any suggestions appreciated @JobV @sytses 

See merge request !2102

Documentation on CI triggers

Closes #3432

## Notes

* Implement build trigger API - https://gitlab.com/gitlab-org/gitlab-ci/merge_requests/229
* Build trigger API - https://gitlab.com/gitlab-org/gitlab-ci/issues/257
* Build pipeline - https://dev.gitlab.org/gitlab/gitlab-ci/issues/282 and https://gitlab.com/gitlab-org/gitlab-ce/issues/3743
* Dependent builds - https://dev.gitlab.org/gitlab/gitlab-ci/issues/328
* Travis docs - https://docs.travis-ci.com/user/triggering-builds/
* Custom variables Circle CI example - https://circleci.com/docs/nightly-builds
* Triggers API (CI) will be done in a separate MR
* Notify https://gitlab.com/gitlab-org/gitlab-ci/issues/368 once done

## Docs needed to change

- [x] `doc/ci/README.md`
- [x] `doc/README.md`

See merge request !2161

Add API support for looking up a user by username

Needed to support Huboard

See merge request !2089

`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 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