projects doesn't seem to be a valid action in this controller

Hi,

This is just a tiny change. Let me know if I'm doing it wrong...

Eaden

See merge request !696

RSpec3

Upgrades rspec to 3.3.0, we're now up-to-date! 🎉

See merge request !831

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Conflicts:
	spec/helpers/application_helper_spec.rb

Replace old logo with new one
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

cc @JobV @sytses

See merge request !848

This is to give pending AJAX requests time to complete before we
navigate away, for example.

Both work, but now we're consistent across the entire app.

In case we end up wanting to use it in Spinach as well.

This fixes spec/mailers/notify_spec

Also only require email_spec in the one place it's used

Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>

Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>

Convert CRLF newlines to LF when committing using the web editor.

Fixes #1823 and https://github.com/gitlabhq/gitlabhq/issues/7950.

Depends on https://gitlab.com/gitlab-org/gitlab_git/merge_requests/29 being merged and a new gitlab_git being released.

cc @jacobvosmaer

See merge request !858

Minor changelog fix

See merge request !861

Avoid "cannot copy directory ... to itself" error on restore (on Docker?)

rake gitlab:backup:restore fails for me in my Docker-hosted Gitlab-CE instance; during the restore, any existing "uploads" directory is backed up by [this code](https://gitlab.com/gitlab-org/gitlab-ce/blob/833bc30/lib/backup/uploads.rb#L23) --

```ruby
    def backup_existing_uploads_dir
      timestamped_uploads_path = File.join(app_uploads_dir, '..', "uploads.#{Time.now.to_i}")
      if File.exists?(app_uploads_dir)
        FileUtils.mv(app_uploads_dir, timestamped_uploads_path)
      end
    end
```

When this executes for me, the ```FileUtils.mv``` parameters are "/home/git/gitlab/public/uploads" and "/home/git/gitlab/public/uploads/../uploads.1407019546"; an exception is raised, producing this double stacktrace:

```
ArgumentError: cannot copy directory /home/git/gitlab/public/uploads to itself /home/git/gitlab/public/uploads/../uploads.1407019546
/home/git/gitlab/lib/backup/uploads.rb:26:in `backup_existing_uploads_dir'
/home/git/gitlab/lib/backup/uploads.rb:18:in `restore'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:73:in `block (4 levels) in <top (required)>'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:30:in `block (3 levels) in <top (required)>'
Errno::EXDEV: Invalid cross-device link @ sys_fail2 - (/home/git/gitlab/public/uploads, /home/git/gitlab/public/uploads/../uploads.1407019546)
/home/git/gitlab/lib/backup/uploads.rb:26:in `backup_existing_uploads_dir'
/home/git/gitlab/lib/backup/uploads.rb:18:in `restore'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:73:in `block (4 levels) in <top (required)>'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:30:in `block (3 levels) in <top (required)>'
Tasks: TOP => gitlab:backup:uploads:restore
(See full trace by running task with --trace)
```

I'm guessing from the first message that ```mv``` walks the destination path to ensure that we're not moving the source into itself -- it doesn't get as far as interpreting the '..', but throws when it sees that the destination appears to start with the source path.

The second stacktrace I have no clue about - maybe it's AUFS- or Docker-related?

I attempted to reproduce this separately with the omnibus distribution in a fresh Ubuntu 14.04 install without Docker involved, and was unable to - backup and restore worked fine. I then tested my theory by FileUtils.expand_path-ing the destination in my own Docker setup code, and that made the problem go away, so that's what this merge request does.

(I'm using backups created and restored on gitlab-ce 7-1-stable, at facfec4b; this is on Ubuntu 14.04 with Docker 1.1.1)

I know I'd look askance at a PR without tests for an unreproducable problem, but even if this is rejected, I'm submitting it anyway because maybe someone else will Google it and find it useful. I'm happy to do more work to improve this if you have suggestions.

See merge request !165

MergeRequest#show performance improvements

This is a first pass on improving the performance of the `MergeRequests#show` page. Notable changes:

- The "Commits" tab is loaded lazily, so the initial page load should be much faster for MRs with many commits.
- Relative timestamps via `timeago` are only initialized once per load instead of `O(n^2)`. This greatly improves frontend rendering times for a large number of commits.
- Refactored `User.find_for_commit` to use a single ARel-generated SQL query instead of the old method which resulted in one query, and could result in up to three.

See merge request !838

Update Code of Conduct to Contributor Covenant 1.1.0

Make snippet filename optional.

Fixes #2384.

See merge request !1866

Disable changing of target branch in new merge request page when a branch has already been specified

### What does this MR do?

This MR prevents a user from changing the target branch inside a new merge request page if the target branch has already been specified (e.g. from the shortcut in the activity feed). A link to "Change branches" is provided to allow the user to do this properly.

### Why was this MR needed?

If a user attempted to create a merge request from a shortcut with a pre-specified target branch (e.g. `master`), the dropdown would suggest that the user could change the branch. However, this did not actually work due to duplicate data elements (see #1830 for more details), and the target branch would always be set to the original, default branch. This would lead to confusion, potentially causing an improper merge request to be created.

### What are the relevant issue numbers?

Closes #1830

### Screenshot

![image](https://gitlab.com/stanhu/gitlab-ce/uploads/eeec4f5d4b66625a14be41e5ecbdc016/image.png)

See merge request !846

Fix Error 500 when one user attempts to access another's personal, internal snippet

### What does this MR do?

This MR fixes an Error 500 that occurred if one user tried to access another's personal, internal snippet. Steps to reproduce:

### Why was this MR needed?

1. Go to `<hostname>/snippets/new`.
2. Select "Internal".
3. Create a snippet. Save the URL (e.g. `<hostname>/snippets/20`)
4. Logout and sign in as another user.
5. Go to the URL in step 3.

### What are the relevant issue numbers?

Closes #1815

See merge request !854