If `merge_error` is ever set after a failure, it is never cleared, even
after a subsequent, successful rebase. We now clear this field whenever
a successful rebase occurs.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/56139
The new two-step Gitaly `Rebase` RPC yields the rebase commit SHA to the
client before proceeding with the rebase.
This avoids an issue where the rebase commit SHA was returned when the
RPC had fully completed, and in some cases this would be after the Rails
`post_receive` worker services had already run. In these situations,
the merge request did not yet have its rebase_commit_sha attribute set
introducing the possibility for bugs (such as previous approvals being
reset).
https://gitlab.com/gitlab-org/gitlab-ee/issues/5966
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).
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
Stan Hu