How to resolve merge conflicts in GitLab?

The latest version of GitLab can resolve the merge conflicts on the web, but I can't.
The link is not clickable and the tooltip says.

These conflicts can not be resolved through GitLab.

How do I enable this feature? Setup or install something else?
The source of the repository is utf-8 and this situation appears on all Merge Request pages.

Here is some information about my system.

GitLab Shell version >= 4.1.1 ? ... OK (4.1.1)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
Git configured with autocrlf=input? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory setup correctly? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Redis version >= 2.8.0? ... yes
Ruby version >= 2.1.0 ? ... yes (2.3.3)
Your git bin path is "/opt/gitlab/embedded/bin/git"
Git version >= 2.7.3 ? ... yes (2.8.4)

System information
System:         Ubuntu 16.04
Current User:   git
Using RVM:      no
Ruby Version:   2.3.3p222
Gem Version:    2.6.6
Bundler Version:1.13.7
Rake Version:   10.5.0
Sidekiq Version:4.2.7

GitLab information
Version:        8.15.2
Revision:       790035f
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
URL:            http://0.0.0.0:8080
HTTP Clone URL: http://0.0.0.0:8080/some-group/some-project.git
SSH Clone URL:  git@0.0.0.0:some-group/some-project.git
Using LDAP:     no
Using Omniauth: no

GitLab Shell
Version:        4.1.1
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
Hooks:          /opt/gitlab/embedded/service/gitlab-shell/hooks/
Git:            /opt/gitlab/embedded/bin/git

Can anyone help me?

This message just means the conflicts are too complex to be resolved using gitlab. You'll have to do it manually.

@jaapz I already know that complex conflicts must be resolved manually.
However, a single line of merge conflict could not be resolved in GitLab either.

Please add a reason to the tooltip. If so, users will understand it more easily.

@1up please see https://docs.gitlab.com/ce/user/project/merge_requests/resolve_conflicts.html#conflicts-available-for-resolution - does that help? I'm not sure adding the specific reason would necessarily help (what if changing that lead to another failure), but I might be wrong!

added ~874211 ~13921 labels

We have an error like this. We can not resolve merge conflicts within files which contain latin characters (á, é, í, ó, ú, ñ). Are those characters UTF-8?

@davidmbroin they can be expressed in UTF-8, or in other encodings. Can you create a public test repository on GitLab.com to demonstrate the problem you're having?

Here you have a project with two merge requests..
This one introduces ñ and you can not be merged using the UI
https://gitlab.com/davidmbroin/test-mr-confilcts/merge_requests/2

This one can be merged using the UI
https://gitlab.com/davidmbroin/test-mr-confilcts/merge_requests/3

@davidmbroin can you make that project public, please?

I'm sorry @smcgivern . It is public now.

@davidmbroin thanks, I still can't see those MRs though 😞 I think you need to edit the project and make the repository and merge requests available publicly, too. Sorry for the hassle here!

It's done! Sorry :)

@davidmbroin thanks! I think the docs are wrong here.

We use Rugged::Index#merge_file to get the conflict results. That returns an encoding-less string for the file contents: https://github.com/libgit2/rugged/blob/v0.24.0/ext/rugged/rugged_index.c#L1101

This gives us a string with the encoding Encoding::ASCII_8BIT:

Encoding::ASCII_8BIT is a special encoding that is usually used for a byte string, not a character string. But as the name insists, its characters in the range of ASCII are considered as ASCII characters. This is useful when you use ASCII-8BIT characters with other ASCII compatible characters.

We can force the encoding to UTF-8, under the assumption that that's what most people use, but then it's possible we would inadvertently change the file's encoding when saving the conflict resolutions if they didn't notice that some characters weren't encoded correctly. Also, as we only display some lines of context around each conflict, the errors might not even be visible by default.

I think we have two options:

1. Update the docs to say that we only support this on files in ASCII-compatible encodings.
2. If we detect a non-ASCII character, try the UTF-8 encoding. If it works, display a warning message that we assumed the file was UTF-8. If it doesn't, refuse to resolve the conflict, as now.

I think 1 is probably the better solution. @DouweM wdyt?

@smcgivern that sounds understandable, but I think we have another issue here because I created and edited that file using the GitLab UI.

@davidmbroin creating through the UI won't make any difference, it's to do with how we get the conflicts back from the underlying repository 🙂

Oh sorry, I misunderstood your previous comment. 😄

@smcgivern Can we detect the encoding in the same way we do for blobs when rendering them? http://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/git/encoding_helper.rb#L17

I don't think we can do exactly that, as we can only support UTF-8 when resolving conflicts, and because we're actually writing to the repo, the stakes are higher. But we could assume UTF-8, and provide a message to that effect.

@stanhu any thoughts here? I see you commented on some encoding-related stuff way back when.

Encoding issues are tricky. Charlock Holmes/libicu has a confidence factor when it evaluates a file, but it's not foolproof. We could attempt to enforce a detect encoding if the confidence level is high (e.g. above 90%).

If we want to focus on source code, different languages also have standards for marking a file as certain encodings. For example, this is Python's. I believe Ruby also has # encoding: UTF-8.

I've been thinking about this a bit more, and maybe the problem isn't what I thought.

1. We read bytes from the repo.
2. We parse some things out of the text.
3. We write bytes back to the repo.

If your file looked like UTF-8, but wasn't, and the conflicts were in the problem section, you'd see that it displayed wrongly. If the conflicts weren't in the problem section, we'd write the same bytes back as we got in the first place. So I think I can just take the first part of @DouweM's suggestion at http://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/git/encoding_helper.rb#L17 - force encoding and check for validity, with no detection - and we'll be fine!

assigned to @smcgivern

mentioned in merge request !9937 (merged)

closed via merge request !9937 (merged)

mentioned in commit blackst0ne/gitlab-ce@0ace54e8

added devopsplan label