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

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

This reverts commit a9fadce3.

This reverts commit 280822cd.

Make project title link to project homepage

Nginx updates

minor updates @ formatting changes to match other versions of file.
Unify formatting of
https://github.com/gitlabhq/gitlabhq/blob/master/lib/support/nginx/gitlab,
https://github.com/gitlabhq/gitlabhq/blob/master/lib/support/nginx/gitlab-ssl,
&
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb

Factor GITLAB_SHELL_VERSION get method

Don't enable IPv4 *only* on nginx.

I came across this issue when initially setting up gitlab and fixed it locally. Today, helping someone else set up their own instance, I came across this issue again:

The sample nginx configuration files disable IPv6 by default, making the server inaccesible unless the remote node has native IPv4. IPv4->IPv6 transition mechanisms don't help if the server have proper IPv6 DNS records in-place, which was the case for both of my servers.

This branch enables IPv4 and IPv6 by default. Older servers with no external IPv6 connectivity will not fail since they'll have a local-link IPv6 address to bind to anyway.

See merge request !231

Create dev fixture projects with fixed visibility

Do not require immediate password reset if specifying a password

Fix attachment ui

Fixes #1571

See merge request !1244

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

Improve white code highlight in comments and wiki

![Screenshot 2014-11-05 16.36.55](https://dev.gitlab.org/uploads/dzaporozhets/gitlabhq/5723848593/Screenshot_2014-11-05_16.36.55.png)

See merge request !1241

Do not mention MR if commit is a part of MR

See merge request !1242