Hi Christian,

On Fri, 28 Jan 2022, Christian Couder wrote:

On Fri, Jan 28, 2022 at 1:58 PM Johannes Schindelin
[off-list ref] wrote:

quoted

On Wed, 26 Jan 2022, Christian Couder wrote:

quoted

On Wed, Jan 26, 2022 at 1:03 PM Johannes Schindelin
[off-list ref] wrote:

quoted

On Wed, 26 Jan 2022, Christian Couder wrote:

quoted

The reason is that I think in many cases when there are conflicts,
the conflicts will be small and the user will want to see them. So
it would be simpler to just have an option to show any conflict
right away, rather than have the user launch another command (a
diff-tree against which tree and with which options?).

That assumes that server-side merge UIs will present merge conflicts in
the form of diffs containing merge conflict markers. Which I don't think
will happen, like, ever.

Please take a look at:

https://docs.gitlab.com/ee/user/project/merge_requests/conflicts.html#resolve-conflicts-in-the-inline-editor

As you can see in the image there are conflict markers in the file
displayed by the server UI.

Please note the difference between what I wrote above (present merge
conflicts in the form of diffs containing merge conflict markers) and what
is shown in the document you linked to (present a file annotated with
merge conflict markers).

There is no diff in that page.

The server UI could just get a diff with the conflicts inside instead
of the full files with conflict inside, as the diff would be smaller
to parse than the full files. So even if it's not shown, the diff
could still be useful.

You really need to get away from talking about this in hypothetical terms.

Also just above the section of the link I sent, there is this section

https://docs.gitlab.com/ee/user/project/merge_requests/conflicts.html#resolve-conflicts-in-interactive-mode

where one can see diff markers in the image.

That's a side-by-side diff. Git cannot even produce those.

quoted

What's more: there are not only conflict markers in the editor,

You don't see the ">>>>>>>"?

Yes, I do. And not only that. I also see that the editor knows very
specifically where the conflict happens.

And since any file can contain `>>>>>>>` _without_ it being a conflict
marker, the editor most likely does not parse the output of Git that
contains a conflict marker. At least I hope it does not because it would
then very easily be confused by strings that look like conflict markers,
but aren't.

Think about our very own test suite, and why we specifically set
`conflict-marker-size=32` for those files. Same reason why the server
backend cannot simply ingest files with conflict markers and then hope to
figure out which `>>>>>>>` are real conflict markers and which are not.

quoted

there is clearly a visual marker next to the line number that
indicates that the editor has a fundamental understanding where the
conflict markers are.

Yeah, so this shows that those markers can be important for the editor.

Of course they are important! That's my point!

quoted

In other words: you are making my case for me that `git merge-tree` should
not generate diff output because it would not even be used.

The other link above in this email actually shows that diffs are used
right now to resolve conflicts.

It shows that Git was not used to generate the diff, is what it shows.

I see that you are still trying to guess what the server-side needs
actually are. It really is time to stop guessing. So I will keep
challenging you to actually look at the GitLab code, to take a stab at
teaching it to use `git merge-tree` to perform merges. And then to come
back with what you learned. I guarantee you that that will be multiple
times more useful than talking about it in hypotheticals.

And you are in such an almost unique position to contribute to this patch
series, to provide that very valuable feedback how `git merge-tree` could
be improved to support actual, real-life server-side code that is
currently in use! So why not make the most out of it?

Ciao,
Johannes