Before, this would:

1. Not use the correct reference for non-JIRA external trackers.
2. Append 'Closes ' if an external tracker was enabled, but no issue matched the
   branch name.

When JIRA or Redmine were enabled and the branch name did not match the
matching regular expression, the `issue_iid` would be `nil`, preventing
users from creating merge requests.

Closes #43193

We stop relying on Gitlab::Git::Env for the RevList class, and use
Gitlab::Git::Repository#run_git methods inteaad. The refactor also fixes
another issue, since we now top using "path_to_repo" (which is a
Repository model method).

Signed-off-by: Rémy Coutable <remy@rymai.me>

check project access on MR create

See merge request gitlab/gitlabhq!2273

(cherry picked from commit 1fe2325d6ef2bced4c5e97b57691c894f38b2834)

43e85f49 check project access on MR create

Closes gitaly#863

Instead of storing detailed rebase error, only a generic message is
stored with MR. The reason is that this message is exposed and displayed
to end user and there is no reason to expose detailed backend
information. Error message is still logged so detailed information
can be found in logfile by admin if needed.

Related #41820

When a project uses fast-forward merging strategy user has
to rebase MRs to target branch before it can be merged.
Now user can do rebase in UI by clicking 'Rebase' button
instead of doing rebase locally.

This feature was already present in EE, this is only backport
of the feature to CE. Couple of changes:
* removed rebase license check
* renamed migration (changed timestamp)

Closes #40301

This does two things:
- Pass commit oids instead of `Gitlab::Git::Commit`s. We only need the
former.
- Depend on only the target repository for conflict listing. For
conflict resolution, treat one repository as a remote one so that we can
implement it as such in Gitaly.

The hook ordering influenced the diffs being generated as these used
values from before the update due to the memoization still being in
place. This commit reorders them and tests against this behaviour.

In CE, this does nothing - the `MergeRequests::BuildService` will, at the time
of writing, never return a description for this case.

In EE, a project can have a default MR template, which will be returned by the
service. Previously we were only using the description passed in the params,
ignoring any already set on the object. Now we fall back to the one set on the
object if there was none in the params, allowing quick actions to be executed
from default MR templates when creating an MR from an issue.

* new merge request can be created by sending an email to the specific
email address (similar to creating issues by email)
* for the first iteration, source branch must be specified in the mail
subject, other merge request parameters can not be set yet
* user should enable "Receive notifications about your own activity" in
user settings to receive a notification about created merge request

Part of #32878

If a merge request was created with a branch name that also matched a tag name,
we'd generate a comparison to or from the tag respectively, rather than the
branch. Merging would still use the branch, of course.

To avoid this, ensure that when we get the branch heads, we prepend the
reference prefix for branches, which will ensure that we generate the correct
comparison.

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Rename classes to (hopefully) clearer names while we're doing that.

This prepares the codebase for a Gitaly migration. See
https://gitlab.com/gitlab-org/gitaly/issues/553

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

The helper creates a fork of a project with all provided attributes,
but skipping the creation of the repository on disk.

Before this change, the MR counter in the sidebar would be wrong if an MR had
been merged since the last update, but not opened or closed, as merging did not
trigger a counter cache update.