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.
* upstream/master:
Ensure we have a project with a repo in GitlabMarkdownHelper specs
Revert "Make sure TraceReader uses Encoding.default_external"
Make sure TraceReader uses Encoding.default_external
Update CONTRIBUTING.md after merging "up-for-grabs" and "Accepting Merge Requests" [ci skip]
Use `:empty_project` where possible in finder specs
Use `empty_project` where possible in controller specs
Use `:empty_project` where possible in helper specs
Don’t count tasks that are not defined as list items correctly
Use a project factory with a repository where necessary
Use `:empty_project` where possible throughout spec/lib
Use hashrocket for dasherized attribute
Remove markdown file extension and add anchor to link
Fixed builds info link on project settings page
Factories with a project association use `:empty_project` by default
Update enviroments.md the example for deleting an environment is missing the "s" in environments. curl --request DELETE --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" "https://gitlab.example.com/api/v3/projects/1/environments/1" wil 404
1. When a merge request is being merged, save the merge commit SHA in
the `in_progress_merge_commit_sha` database column.
2. The `pre-receive` hook looks for any locked (in progress) merge
request with `in_progress_merge_commit_sha` matching the `newrev` it
is passed.
3. If it finds a matching MR, the merge is legitimate.
4. Update `git_access_spec` to test the behaviour we added here. Also
refactored this spec a bit to make it easier to add more contexts / conditions.
