Hi Christian, 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. What's more: there are not only conflict markers in the editor, 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. Which means that the conflict markers must have been generated independently of Git rather than parsed in some random diff that was produced by Git. 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. > > In short: I completely disagree that we should introduce a new command, > > and I also completely disagree that the `merge-tree` command should output > > any diffs. > > > > I do agree that we need to be mindful of what we actually need, and in > > that regard, I reiterate that we need to let concrete use cases guide us. > > As part of GitLab, you might be in an excellent position to look at > > GitLab's concrete server-side needs when it comes to use `git merge-tree` > > to perform merges. > > I hope I provided a concrete use case with the link above. Sorry, I apparently was a bit unclear. In the context of discussing `git merge-tree`, a low-level Git command, when I talk about a user, I do not mean a human being, but a program that calls that command and parses its output. Corollary: by "use case" I refer to a concrete implementation of a server-side merge operation, I refer to backend code that currently calls into libgit2 to perform the merge, and would benefit from calling `git merge-tree` instead. Such a use case informs us about the type and amount of information that is required of the code that is currently being discussed in this mail thread. And I highly doubt that you will find such a use case that wants libgit2 (and later, `git merge-tree`) to generate diffs. Because _diffs_ are certainly _not_ what is consumed by the inline editor you referenced. Of course, I am still left guessing what the server-side needs concretely, because that is not at all obvious from the user-facing web site to which you sent me. What is needed is a good, hard look at the actual _code_, the code that calls into libgit2 to perform a merge, and that could instead spawn a `git merge-tree` process to accomplish the same thing. We need to get away from hypothetical scenarios. They're not helping. Ciao, Johannes
