Hi Christian, On Fri, 28 Jan 2022, Christian Couder wrote: > On Fri, Jan 28, 2022 at 1:58 PM Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > On Wed, 26 Jan 2022, Christian Couder wrote: > > > > > On Wed, Jan 26, 2022 at 1:03 PM Johannes Schindelin > > > <Johannes.Schindelin@xxxxxx> wrote: > > > > > > > > On Wed, 26 Jan 2022, Christian Couder wrote: > > > > > > > > > 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. > > 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. > > 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! > > 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
