delta/gitlab/gitlab-ce.git - gitlab.com: gitlab-org/gitlab-ce.git

	Commit message (Collapse)	Author	Age	Files	Lines
*	Add latest changes from gitlab-org/gitlab@master	GitLab Bot	2020-06-24	1	-1/+1
\|
*	Add frozen_string_literal to spec/lib (part 1)	Thong Kuah	2019-07-26	1	-0/+2
\| \| \| \| \|	Using the sed script from https://gitlab.com/gitlab-org/gitlab-ce/issues/59758
*	Cache `#can_be_resolved_in_ui?` git operationscache-refactor	Alejandro Rodríguez	2018-03-08	1	-0/+32
\|
*	Refactor conflict resolution to contain git ops within Gitlab::Git	Alejandro Rodríguez	2017-10-12	1	-1/+1
\| \| \| \| \|	This prepares the codebase for a Gitaly migration. See https://gitlab.com/gitlab-org/gitaly/issues/553
*	Remove superfluous lib: true, type: redis, service: true, models: true, ↵	Rémy Coutable	2017-07-27	1	-1/+1
\| \| \| \| \| \|	services: true, no_db: true, api: true Signed-off-by: Rémy Coutable <remy@rymai.me>
*	Fix conflict resolution from corrupted upstreamfix-conflict-resolution-with-corrupt-repos	Sean McGivern	2017-05-12	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	Add more tests for conflicts	Sean McGivern	2016-08-12	1	-2/+2
\|
*	Handle multiple merge conflict files in collection	Sean McGivern	2016-08-12	1	-0/+24