summaryrefslogtreecommitdiff
path: root/Gemfile.lock
diff options
context:
space:
mode:
authorLuke Duncalfe <lduncalfe@gitlab.com>2019-05-02 17:30:07 +0000
committerDouwe Maan <douwe@gitlab.com>2019-05-02 17:30:07 +0000
commit49cb4b3dfcb88403ca7c7e866d94a9fbb08be442 (patch)
tree4d25f584337bd357f137ded0927207fd8de6fae4 /Gemfile.lock
parent4e67122e389708d766a2a90daa059f05b0f980c5 (diff)
downloadgitlab-ce-49cb4b3dfcb88403ca7c7e866d94a9fbb08be442.tar.gz
Add support for two-step Gitaly Rebase RPC
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
Diffstat (limited to 'Gemfile.lock')
-rw-r--r--Gemfile.lock4
1 files changed, 2 insertions, 2 deletions
diff --git a/Gemfile.lock b/Gemfile.lock
index 4db00ba4e18..053dd322b01 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -283,7 +283,7 @@ GEM
gettext_i18n_rails (>= 0.7.1)
po_to_json (>= 1.0.0)
rails (>= 3.2.0)
- gitaly-proto (1.26.0)
+ gitaly-proto (1.27.0)
grpc (~> 1.0)
github-markup (1.7.0)
gitlab-default_value_for (3.1.1)
@@ -1056,7 +1056,7 @@ DEPENDENCIES
gettext (~> 3.2.2)
gettext_i18n_rails (~> 1.8.0)
gettext_i18n_rails_js (~> 1.3)
- gitaly-proto (~> 1.26.0)
+ gitaly-proto (~> 1.27.0)
github-markup (~> 1.7.0)
gitlab-default_value_for (~> 3.1.1)
gitlab-labkit (~> 0.2.0)