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

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

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

Conflicts:
	app/views/admin/users/show.html.haml

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

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

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

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

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

Conflicts:
	features/steps/project/merge_requests.rb

Close #178 Nginx conf default_host documentation

This closes #178
We're just making it clear that some nginx installs such as by default on recent Ubuntu's, the /etc/nginx/sites-enabled/default file will conflict the listen line of the gitlab nginx conf's due to the default_server directive.

changed installation.md to identify the issue to a user
added notes to both nginx configs for gitlab and gitlab-ssl
[ci-skip

See merge request !225

Link an users avatar to the fullsize version

When we want to see the fullsize avatar of a user we can click the avatar on the profile page and the fullsize version will be opened in a new window/tab.

See merge request !415

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>

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

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

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