Commit graph

8 commits

Author SHA1 Message Date
GitLab Bot
c59765a50a Add latest changes from gitlab-org/gitlab@master 2020-06-24 18:09:03 +00:00
Thong Kuah
f540ffcef6 Add frozen_string_literal to spec/lib (part 1)
Using the sed script from
https://gitlab.com/gitlab-org/gitlab-ce/issues/59758
2019-07-26 13:25:07 +12:00
Alejandro Rodríguez
bb2bf39ddf Cache #can_be_resolved_in_ui? git operations 2018-03-08 11:54:21 -03:00
Alejandro Rodríguez
3fcab51ebb Refactor conflict resolution to contain git ops within Gitlab::Git
This prepares the codebase for a Gitaly migration. See
https://gitlab.com/gitlab-org/gitaly/issues/553
2017-10-12 22:03:14 -03:00
Rémy Coutable
ddccd24c13 Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true
Signed-off-by: Rémy Coutable <remy@rymai.me>
2017-07-27 14:31:53 +02:00
Sean McGivern
ad2bfeb857 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-12 20:47:51 +01:00
Sean McGivern
ce7eb4e492 Add more tests for conflicts 2016-08-12 23:24:48 +03:00
Sean McGivern
a1c7961217 Handle multiple merge conflict files in collection 2016-08-12 23:24:43 +03:00