Validate README format
Take the first previewable README file as project's README, otherwise if
none file is available, or we can't preview any of them, we assume that
project doesn't have a README file.
Fixes#3978
Expire view caches when application settings change
If the admin disables Gravatar, for example, before the views would not invalidate. Now they invalidate automatically when this happens.
Closes#5728
See merge request !2280
Attempting to use the /projects/:id API by specifying :id in
"namespace/project" format would always result in a 404 if the namespace
contained a dot.
The reason? From http://guides.rubyonrails.org/routing.html#specifying-constraints:
"By default the :id parameter doesn't accept dots - this is because the dot is
used as a separator for formatted routes. If you need to use a dot within an
:id add a constraint which overrides this - for example id: /[^\/]+/ allows
anything except a slash."
Closes https://github.com/gitlabhq/gitlabhq/issues/9573
While Safari supports the policy, it does not (currently, as of 9.x)
recognize `origin-when-cross-origin` as a valid value, so we omit the
policy entirely under Safari.
Closes#5609
The introduction of ActiveJob and `deliver_now` in 7f214cee7 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
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
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` (?)~~


Page when you fail CAPTCHA:

See merge request !2216
`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
Fix Error 500 when doing a search in dashboard before visiting any project
If a search turned up an issue, under certain conditions you would see this error:
```
ActionView::Template::Error (undefined method `path_with_namespace' for nil:NilClass):
6: - if issue.description.present?
7: .description.term
8: = preserve do
9: = search_md_sanitize(markdown(issue.description))
10: %span.light
11: #{issue.project.name_with_namespace}
12: - if issue.closed?
lib/gitlab/markdown/upload_link_filter.rb:36:in `build_url'
lib/gitlab/markdown/upload_link_filter.rb:31:in `process_link_attr'
lib/gitlab/markdown/upload_link_filter.rb:18:in `block in call'
lib/gitlab/markdown/upload_link_filter.rb:17:in `call'
lib/gitlab/markdown.rb:127:in `gfm'
lib/gitlab/markdown.rb:24:in `render'
app/helpers/gitlab_markdown_helper.rb:61:in `markdown'
app/views/search/results/_issue.html.haml:9:in `block in _app_views_search_results__issue_html_haml__4127460390996300432_59973760'
app/views/search/results/_issue.html.haml:8:in `_app_views_search_results__issue_html_haml__4127460390996300432_59973760'
app/views/search/_results.html.haml:20:in `_app_views_search__results_html_haml__589475855773452465_61761440'
app/views/search/show.html.haml:5:in `_app_views_search_show_html_haml___1852335078065998536_69780120'
```
Confirmed this is issue still happens in GitLab 8.4, and it also happens on GitLab.com. Here's how to reproduce:
1. Login in a new browser.
2. Enter a search term on the top right that will land a hit in the "Issues" (e.g. GitLab).
3. Click on "Issues" tab. You should get an Error 500.
The issue is that @project isn't assigned to anything.
See merge request !2110
If a search turned up an issue, under certain conditions you would see this error:
```
ActionView::Template::Error (undefined method `path_with_namespace' for nil:NilClass):
6: - if issue.description.present?
7: .description.term
8: = preserve do
9: = search_md_sanitize(markdown(issue.description))
10: %span.light
11: #{issue.project.name_with_namespace}
12: - if issue.closed?
lib/gitlab/markdown/upload_link_filter.rb:36:in `build_url'
lib/gitlab/markdown/upload_link_filter.rb:31:in `process_link_attr'
lib/gitlab/markdown/upload_link_filter.rb:18:in `block in call'
lib/gitlab/markdown/upload_link_filter.rb:17:in `call'
lib/gitlab/markdown.rb:127:in `gfm'
lib/gitlab/markdown.rb:24:in `render'
app/helpers/gitlab_markdown_helper.rb:61:in `markdown'
app/views/search/results/_issue.html.haml:9:in `block in _app_views_search_results__issue_html_haml__4127460390996300432_59973760'
app/views/search/results/_issue.html.haml:8:in `_app_views_search_results__issue_html_haml__4127460390996300432_59973760'
app/views/search/_results.html.haml:20:in `_app_views_search__results_html_haml__589475855773452465_61761440'
app/views/search/show.html.haml:5:in `_app_views_search_show_html_haml___1852335078065998536_69780120'
```