Client Preparation: Merge Request: Conflict Resolver
~Conversation: #551 (closed)
The GitLab conflict resolution code needs to be migrated to Gitaly. In order to do this, the GitLab-CE codebase needs to be prepared for this change, through several refactors:
-
Conflict resolution handling should become contained within the
GitLab::Git
module- It should not have dependencies outside of
GitLab::Git
- It should not have dependencies on services such as Redis, Database etc
- It should not have dependencies outside of
-
Conflict resolution needs to be refactored to use a RPC request-response calling style
- The calling interface should take simple string references to branch names, commit shas, storage and repository path references.
- The calling interface should not be passed activerecord objects, rugged objects, or other objects
- The response should return all the information that the caller requires. So, for example, if the caller renders a template that contains the commit message, then this needs to be passed back from the interface. In order words, the caller should not need to instantiate a rugged object in order to obtain information after making the call - everything it needs should be returned by the new conflict resolution handler.
- The interface should send all the required information up front and should not rely on callback style interfaces to obtain more information during the call
Process
Current
Step 1: Client Preparation (this task):
Step 3: Gitaly Migration (the future):
References
calls
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/conflict/file_collection.rb#L15-26
calls
Example
This code is a good example of a migration ready git operation.
-
It doesn't contain any Rugged or ActiveRecord models in it's method signature or return values.
-
It's easy to serialize and deserialize over the wire