[ci skip]

Fix remote mirror stuck on started issue

Fixes https://gitlab.com/gitlab-org/gitlab-ee/issues/590

I think the issue was that after a mirror update while the remote mirror is in `started`, this is never picked up again by the worker. There has been a few problems with the remote mirror workers being killed manually due to some performance issues - that will increase the chances that the mirror remained in the `started` status.

See merge request !491

Fix suggested approvers on MR update

This was three issues combining:

1. https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/470 didn't apply the same coercion of the `approvals_before_merge` param to editing an existing MR as there was for creating a new MR. This meant that creating a new MR with the same number of approvers as the target project, editing it, not changing anything, and clicking Save would produce a validation error.
2. `set_suggested_approvers` wasn't called in a couple of places where we render the MR edit form (like the above).
3. The number of approvals used for clamping the `approvals_before_merge` param was based on the _source_ project, not the _target_ project (unlike the model validation).

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/18946, closes https://gitlab.com/gitlab-org/gitlab-ee/issues/710, and closes https://gitlab.com/gitlab-org/gitlab-ee/issues/711.

See merge request !496

Remove .form-horizontal from git hooks page

Fix vertical alignment of git-hooks page   

![Screen_Shot_2016-06-23_at_10.34.06_AM](/uploads/aadc7d24238daad3bee3f748e5391b87/Screen_Shot_2016-06-23_at_10.34.06_AM.png)

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/18730

See merge request !499

Update changelogs



See merge request !498

Revert "Merge branch '388-option-to-disallow-author-to-approve-merge-request' into 'master'"

This reverts commit 09ab819e, reversing
changes made to 041f3c27.

This reverts !455 as per https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/479#note_12609455

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/18759

See merge request !493

This reverts commit 09ab819e, reversing
changes made to 041f3c27.

Geo documentations improvement for 8.9

Important changes:

* Added note that we don't support MySQL (I don't know if we should add to the limitations or not)
* Added related files to the TOC
* Added disaster recovery instructions (we don't support this, but there are manual steps if anyone need)
* Added troubleshooting instructions

From recent feedback:

We need to improve the SSH keys part of setup instructions, as it's unclear which ssh key you have to add at geo nodes screen and that you have to pre-authorize the connection once (add to known_hosts), so clones can actually work.

Fixes gitlab-org/gitlab-ee#344

See merge request !431

Don't reset approvals after rebase from UI

Rebasing from the UI should be considered a 'safe' action, so this
should ignore the 'reset approvals on push' project
setting.

Unfortunately, as rebase is implemented by working directly on
a copy of the repository and pushing (as it's not supported fully by
libgit2), we can't detect this purely with information available to the
PostReceive job. If we used commit metadata, the MR author could also
add the same metadata and push without resetting approvals.

To work around this, add a new column to the MergeRequest model to store
the SHA from the rebase action. (Ensure that this is set before pushing,
to avoid a race condition!) Then, in PostReceive, don't reset approvals
if the pushed SHA matches the SHA stored in the database.

![Approval_reset](/uploads/cc3ae5f417d403b271aa25884af8f54b/Approval_reset.gif)

Closes #372.

@DouweM this was marked as 8.9 but I think it's a bit close to be adding ~"Pick into Stable" - what's the procedure for this? I'm open to changing this implementation; @vsizov and I discussed it this morning and this was the simplest solution we came up with.

See merge request !489

Fix link to permissions



See merge request !495

Rebasing from the UI should be considered a 'safe' action, so this
should ignore the 'reset approvals on push' project
setting.

Unfortunately, as rebase is implemented by working directly on
a copy of the repository and pushing (as it's not supported fully by
libgit2), we can't detect this purely with information available to the
PostReceive job. If we used commit metadata, the MR author could also
add the same metadata and push without resetting approvals.

To work around this, add a new column to the MergeRequest model to store
the SHA from the rebase action. (Ensure that this is set before pushing,
to avoid a race condition!) Then, in PostReceive, don't reset approvals
if the pushed SHA matches the SHA stored in the database.

Users with master permissions cannot edit the file locks

Fixes https://gitlab.com/gitlab-org/gitlab-ee/issues/702

See merge request !494

Set no container on locked files sub nav

Closes #703 

![Screen_Shot_2016-06-21_at_12.44.27_PM](/uploads/5e95a838256650d07260ea2639e3a302/Screen_Shot_2016-06-21_at_12.44.27_PM.png)

cc @dzaporozhets 

See merge request !492

Allow setting required approval count on MR

Closes #314.

See merge request !470

Address review comments for !440

See merge request !486