Conflicts:
	Gemfile
	VERSION
	app/assets/javascripts/project.js.coffee
	app/assets/javascripts/users_select.js.coffee
	app/controllers/projects/services_controller.rb
	app/models/project.rb
	app/views/groups/edit.html.haml
	features/project/service.feature
	features/steps/project/services.rb
	spec/models/concerns/mentionable_spec.rb

Actions in the inbox

Related to #1607

See merge request !1247

RAM Requirements update

512MB of RAM is not enough to install using omnibus-gitlab.

Installation will fail in very random places.

Manual installation might also fail with this low amount of RAM.

See merge request !1249

Performance improvements

Push 1k commits cause 1k sql queries to collect commit author. But this variable was used only in 20 commits (from 1000).
So we did 980 sql queries without using it. This MR fixes it.

See merge request !1250

fixes the `block_removed_ldap_users` rake task

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

Custom git hook documentation

Merge branch 'commit-comments' of https://gitlab.com/jeroenj/gitlab-ce into jeroenj/gitlab-ce-commit-comments
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Conflicts:
	CHANGELOG

Drop all Postgres sequences during backup restore

See merge request !1226

Conflicts:
	CHANGELOG

In e23a26ae (and later 1bc99369) the API for Gitlab::LDAP::Adapter was
changed. I assume this rake task was an oversight in the refactoring of
the changed class.

While being on it, I noticed that already blocked users cannot be
blocked again.

Add issue edited timestamp

Comments already have this feature.
So, I think, issues should also have it.
![Снимок экрана 2014-11-08 в 17.07.10](https://gitlab.com/uploads/vernik91/gitlab-ce/4e87a15130/%D0%A1%D0%BD%D0%B8%D0%BC%D0%BE%D0%BA_%D1%8D%D0%BA%D1%80%D0%B0%D0%BD%D0%B0_2014-11-08_%D0%B2_17.07.10.png)

See merge request !235

Issue-280 Send notifications when a note is added to a commit and author...

Factor regex error messages with spec API tests

Bump gitlab shell

See merge request !1248

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

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

Prevent post-receive error when push to project with dead forks

Fixes gitlab/gitlab-cloud#173

See merge request !1246

Move new blob commit message textarea below editor

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

If project has open merge request from fork and this fork was removed
before merge request was closed it cause exception during push
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Update release documentation to use release tools

See merge request !1245

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

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

Conflicts:
	CHANGELOG
	VERSION

Conflicts:
	CHANGELOG-EE
	VERSION

Automate upgrader shell version

/cc @marin

See merge request !1237

Remove unused javascript

projects:teams:members:index doesn't exists

See merge request !234

Better merge request manual instructions

I noticed the current instructions for manually merging a merge request that was submitted from a fork could create unnecessary merge requests or strange history. Imagine this:

1. Alice creates a repository and commits / pushes a single commit with SHA1 `A` to `master`.
2. Bob forks this repository and creates a new branch `myfeature` on `master` (`A`)
3. Alice commits `B` to `master` (which has the parent `A`)
4. Bob creates two commits on `myfeature` `P` and `Q`.
5. Bob submits the merge request to merge his `myfeature` into Alice's `master` branch.
6. Alice follows the manual merge request instructions:
  1. `git checkout -b bob/repo-myfeature master`
  2. `git pull http://... myfeature`

The branch `bob/repo-myfeature` was created from Alice's current `master`, which was `B`. When the `pull` is executed, git will fetch Bob's branch and then merged the fetched branch `Q` into the current branch's location `B`. This creates an unnecessary merge commit from `master` into the branch Alice is trying to merge. No harm is done, but the history is a bit messier.

This is even worse if Alice has set `git pull` to rebase by default. In this case, the commit `B` is rebased on top of `Q`. When Alice checks out `master` and merges in the branch, there will actually be a duplicate `B` commit.

These new instructions instead tell the user to fetch Bob's `myfeature` branch. This will fetch the necessary commits `P` and `Q` and create a temporary ref `FETCH_HEAD` pointing to `Q`. Alice will then create her local `bob/repo-myfeature` branch starting at `FETCH_HEAD`. No unnecessary merge commits, and no accidental rebasing.

See merge request !16