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

* 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.

Adds a rubocop rule (with autocorrect) to ensure line break after guard clauses.

Don’t show source project name when user does not have access

See merge request !2081

Closes #28890

add changelog entry

replace local variables `merge_request` with instance ones

modify `MergeRequests::BuildService` to fix failed tests

extract `assign_target_project` method

remove unnecessary instance variables

remove exclamation marks and rewrite conditionals to improve readability

extract `params_does_not_contain_branches?` method, rename `unprepared_merge_request` method to `uncreatable_merge_request`

replace instance variables `merge_request` and `error_messages` with getters and setters; divide `set_title_and_description` method on two separate ones

refactor `execute` method

return `set_title_and_description` method

rename `branches_selected?` method to `branches_present?` to make it more different from `branches_specified?`

fixes after discussion

renamed method branches_valid?

fix space

return assigning methods into `execute` method

simplify `find_target_branch` and `find_source_project` methods

fix spec `merge request issuable record that supports slash commands in its description and notes`

commits from the other repository. We'll cleanup
the tmp ref after we're done with our business.

Replace issue access checks with use of IssuableFinder

Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867

## Which fixes are in this MR?

 - Potentially untested  
 - No test coverage  
 - Test coverage of some sort exists (a test failed when error raised)  
 - Test coverage of return value (a test failed when nil used)  
 - Permissions check tested

### Issue lookup with access check

Using `visible_to_user` likely makes these security issues too. See [Code smells](#code-smells).

- [x]  app/finders/notes_finder.rb:15 [`visible_to_user`]
- [x]  app/views/layouts/nav/_project.html.haml:73 [`visible_to_user`] [`.count`]
- [x]  app/services/merge_requests/build_service.rb:84 [`issue.try(:confidential?)`]
- [x]  lib/api/issues.rb:112 [`visible_to_user`]
  - CHANGELOG: Prevented API returning issues set to 'Only team members' to everyone
- [x]  lib/api/helpers.rb:126 [`can?(current_user, :read_issue, issue)`] Maybe here too?
- [x]  lib/gitlab/search_results.rb:53 [`visible_to_user`]

### Previous discussions
- [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#b2ff264eddf9819d7693c14ae213d941494fe2b3_128_126
- [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#7b6375270d22f880bdcb085e47b519b426a5c6c7_87_87

See merge request !2031

Merge request !7163 caused an error message to appear on the Merge
Request form when it was first loaded by the user. This commit fixes
that regression bug.

If source branch or target branch doesn't exist in the project, display
form validation errors. Previously, this caused a 500 error code.

- Added an extra new line to the prepend of the Close message

Fixes #21710

This object will manage Gitlab::Git::Compare instances

Rails's form helpers use the `$attr_before_type_cast` method where
available, and this value only appears to be updated on assignment, not
when the object is mutated in some other way:

    [1] pry(main)> mr = MergeRequest.new
    => #<MergeRequest:0x007fcf28395d88 ...>
    [2] pry(main)> mr.description = 'foo'
    => "foo"
    [3] pry(main)> mr.description << ' bar'
    => "foo bar"
    [4] pry(main)> mr.description
    => "foo bar"
    [5] pry(main)> mr.description_before_type_cast
    => "foo"
    [6] pry(main)> mr.description += ' bar'
    => "foo bar bar"
    [7] pry(main)> mr.description_before_type_cast
    => "foo bar bar"

This reverts commit 3e991230.

# Conflicts:
#	app/models/project.rb

If a branch starts with an issue's IID, followed by a hyphen, the
description will be updated to say that is closes the issue. This also
updates the title of the merge request to 'Resolves "$issue-title"', as
long as:
- There is more than one commit in the merge request (if there is only
  one commit, the commit's title will be used as before)
- The issue's IID is valid for the project

Fixes #15591.

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

Given the branch name 'mep-mep' with an iid being 1,
the current way, master's way, would yield a branch name of
1-mep-mep. The problem for larger projects however would be that
a developer might forget what iid the issue was.

When this developer would try to tab complete it would:
- Or result in 20+ branches possibly
- Or start with the wrong digit, try again with digit++
  - Would see 20 branches, repeat

Thus the obvious way of solving this is letting the dev tab complete
on the issue title, which is easier to remember.

This reverts commit 5daf44b7, reversing
changes made to 2f706fbd.

This reverts commit 957e849f, reversing
changes made to 6b9dbe9f.

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

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