- Hint essentially states that a user should first update their target branch
  with upstream changes and then perform the merge.

Closes #50405

Fix #47913 (again), revert !21180, fix regression of !8652, improve !20137

This isn't interesting most of the time and is may go over other flash banners.

These don't have performance data saved as they use Grape.

Filipa Lacerda authored 6 years ago and Jose Ivan Vargas Lopez committed 6 years ago

When backend sends HTML it requires frontend to append it to the DOM causing
XSS vulnerabilities. By removing the `<br>` we avoid those vulnerabilities

When using ruby interpolation in externalized strings, they can't be
detected. Which means they will never be presented to be translated.

To mix variables into translations we need to use `sprintf`
instead.

Instead of:

    _("Hello #{subject}")

Use:

    _("Hello %{subject}) % { subject: 'world' }

Users importing from Bitbucket Cloud, Bitbucket Server, or GitHub
often complained about getting failed imports due to 422 errors.
This change ensures that project names are imported with names that
are guaranteed to pass the regular expression validation.

Part of #50021

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

Remote mirrors only get created when the URL changes, However, during the GCP
migration, the remote mirror did not get created automatically. Plus, there's
no guarantee someone restoring a repository from backup would have this
remote. We now add the remote each time we attempt to fetch from the
repository.

This works because Gitaly doesn't throw up an exception or error if the
remote already exists:
https://gitlab.com/gitlab-org/gitaly/issues/1317

In the future, we should attempt to add if the remote doesn't exist:
https://gitlab.com/gitlab-org/gitaly/issues/1316

Closes #50562

This fixes a regression in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20916.
We now only use the full commit count for the initial push to the default branch.
Otherwise, we rely on the number of commits that we calculated occurred in the push.

The original behavior in 11.1.4:

1. When a new branch is pushed, `@push_commits_count` was set to the total
number of refs available for the branch.
2. For other branches, `@push_commits_count` would remain `nil`.
3. `GitPushService#build_push_data` would build the push data with
`@push_commits_count`.
4. If this were `nil`, it would be set to the right value here:
https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.1.4/lib/gitlab/data_builder/push.rb#L60

Broken behavior:

1. `GitPushService#push_commits_count` is always called.
2. The total number of commits is therefore always equal to the total number of refs available.

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

When a diff has a significant number of commits, the previous behavior would
attempt to render the Markdown on all the commit messages but only display
1000 of them. To avoid additional work, we only need to render the Markdown
on the set that is displayed.

This is more idiomatic than checking membership explicitly.

We usually want a feature flag to be disabled by default and
hide the feature until it's enabled.

This is an unconventional use: when the flag is enabled, it will
"DISABLE" the behavior.

Previously `SystemHookPushWorker` would always be called after a push event,
and this would queue a Sidekiq job regardless of whether any system hooks
needed that event. Moreover, another call inside `Project#execute_hooks` would
also fire system hooks if they existed.

This change both removes the duplicate system hook calls. For installations
without system hooks for push events, this change also can save significant
amount of RAM used by Redis.

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