diff options
| author | Sean McGivern <sean@gitlab.com> | 2017-05-11 18:23:02 +0300 |
|---|---|---|
| committer | Sean McGivern <sean@gitlab.com> | 2017-05-12 22:47:51 +0300 |
| commit | ad2bfeb85756db8c4cea9290be743665efd1c918 (patch) | |
| tree | cf51b926c348db7a7f5df26117a692f55416fe25 /spec/lib/gitlab/conflict | |
| parent | aec53bab05afd0a20b15bd9311643f8bf5efd140 (diff) | |
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.
Diffstat (limited to 'spec/lib/gitlab/conflict')
| -rw-r--r-- | spec/lib/gitlab/conflict/file_collection_spec.rb | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/spec/lib/gitlab/conflict/file_collection_spec.rb b/spec/lib/gitlab/conflict/file_collection_spec.rb index 39d892c18c0..27f23ea70dc 100644 --- a/spec/lib/gitlab/conflict/file_collection_spec.rb +++ b/spec/lib/gitlab/conflict/file_collection_spec.rb @@ -2,7 +2,7 @@ require 'spec_helper' describe Gitlab::Conflict::FileCollection, lib: true do let(:merge_request) { create(:merge_request, source_branch: 'conflict-resolvable', target_branch: 'conflict-start') } - let(:file_collection) { Gitlab::Conflict::FileCollection.new(merge_request) } + let(:file_collection) { described_class.read_only(merge_request) } describe '#files' do it 'returns an array of Conflict::Files' do |