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

Include non-default ssh key location info

Fixes #875

Provide help for people who aren't SSH-clued by indicating
how to point to key files that have been named something
other than the default. A lot of people seem to assume that
the filename they choose is irrelevant and then wonder why
their private key is not being found by simple 'ssh' commands.

See merge request !507

Closes #1815

Fixes #2384.

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

Closes #1830

Refactor and spec line highlighting Javascript

- Replaces the fragile Spinach tests for this feature with Jasmine tests
- The "Don't scroll the page when we click a line number" behavior now works as expected

See merge request !820

Show user 2FA status on Admin::Users#show

| Enabled | Disabled |
| ------- | -------- |
| ![Screen_Shot_2015-06-19_at_2.58.42_PM](https://gitlab.com/gitlab-org/gitlab-ce/uploads/b81f6a992366105c14e03852385b28f0/Screen_Shot_2015-06-19_at_2.58.42_PM.png) | ![Screen_Shot_2015-06-19_at_2.58.30_PM](https://gitlab.com/gitlab-org/gitlab-ce/uploads/7bb8fd11b6c27615eef19154ffabe2de/Screen_Shot_2015-06-19_at_2.58.30_PM.png) |

Closes internal https://dev.gitlab.org/gitlab/gitlabhq/issues/2415

See merge request !851

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

Provide help for people who aren't SSH-clued by indicating
how to point to key files that have been named something
other than the default. A lot of people seem to assume that
the filename they choose is irrelevant and then wonder why
their private key is not being found by simple 'ssh' commands.

Starting shell document to GitLab basics

I added a new branch for all the changes on this MR https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/1863

Everything should look nicer now :)

See merge request !1869

Define 'everyone'

See merge request !1872

Update maintenance documentation to explain no need to recompile asssets for omnibus installations

See merge request !847