gitlab-org--gitlab-foss/app/services/merge_requests/conflicts/base_service.rb

# frozen_string_literal: true

module MergeRequests
  module Conflicts
    class BaseService
      attr_reader :merge_request, :params

      def initialize(merge_request, params = {})
        @merge_request = merge_request
        @params = params
      end
    end
  end
end
Enable more frozen string in app/services/*/.rb Partially addresses #47424. 2018-07-17 12:50:37 -04:00			`# frozen_string_literal: true`

Fix conflict resolution from corrupted upstream I don't know why this happens exactly, but given an upstream and fork repository from a customer, both of which required GC, resolving conflicts would corrupt the fork so badly that it couldn't be cloned. This isn't a perfect fix for that case, because the MR may still need to be merged manually, but it does ensure that the repository is at least usable. My best guess is that when we generate the index for the conflict resolution (which we previously did in the target project), we obtain a reference to an OID that doesn't exist in the source, even though we already fetch the refs from the target into the source. Explicitly setting the source project as the place to get the merge index from seems to prevent repository corruption in this way. 2017-05-11 11:23:02 -04:00			`module MergeRequests`
			`module Conflicts`
			`class BaseService`
Add latest changes from gitlab-org/gitlab@master 2021-07-21 17:10:10 -04:00			`attr_reader :merge_request, :params`
Fix conflict resolution from corrupted upstream I don't know why this happens exactly, but given an upstream and fork repository from a customer, both of which required GC, resolving conflicts would corrupt the fork so badly that it couldn't be cloned. This isn't a perfect fix for that case, because the MR may still need to be merged manually, but it does ensure that the repository is at least usable. My best guess is that when we generate the index for the conflict resolution (which we previously did in the target project), we obtain a reference to an OID that doesn't exist in the source, even though we already fetch the refs from the target into the source. Explicitly setting the source project as the place to get the merge index from seems to prevent repository corruption in this way. 2017-05-11 11:23:02 -04:00
Add latest changes from gitlab-org/gitlab@master 2021-07-21 17:10:10 -04:00			`def initialize(merge_request, params = {})`
Fix conflict resolution from corrupted upstream I don't know why this happens exactly, but given an upstream and fork repository from a customer, both of which required GC, resolving conflicts would corrupt the fork so badly that it couldn't be cloned. This isn't a perfect fix for that case, because the MR may still need to be merged manually, but it does ensure that the repository is at least usable. My best guess is that when we generate the index for the conflict resolution (which we previously did in the target project), we obtain a reference to an OID that doesn't exist in the source, even though we already fetch the refs from the target into the source. Explicitly setting the source project as the place to get the merge index from seems to prevent repository corruption in this way. 2017-05-11 11:23:02 -04:00			`@merge_request = merge_request`
Add latest changes from gitlab-org/gitlab@master 2021-07-21 17:10:10 -04:00			`@params = params`
Fix conflict resolution from corrupted upstream I don't know why this happens exactly, but given an upstream and fork repository from a customer, both of which required GC, resolving conflicts would corrupt the fork so badly that it couldn't be cloned. This isn't a perfect fix for that case, because the MR may still need to be merged manually, but it does ensure that the repository is at least usable. My best guess is that when we generate the index for the conflict resolution (which we previously did in the target project), we obtain a reference to an OID that doesn't exist in the source, even though we already fetch the refs from the target into the source. Explicitly setting the source project as the place to get the merge index from seems to prevent repository corruption in this way. 2017-05-11 11:23:02 -04:00			`end`
			`end`
			`end`
			`end`