For example, if a topic branch renames a file differently than the main branch, there is a really good chance that the user tasked with merging the topic branch will have to do a whole lot more than just click a few buttons to perform that task. There might very well be the need to edit files that do not contain merge conflict markers (I like to call those cases "non-semantic merge conflicts"), and almost certainly local testing will be necessary. So I guess the best we can do in those complicated cases is to give a comprehensive overview of the problems in the web UI, with the note that this merge conflict has to be resolved on the local side. Which brings me to the next concern: since `merge-tree` is a low-level tool meant to be called by programs rather than humans, we need to make sure that those messages remain machine-parseable, even if they contain file names. Concretely: while I am not currently aware of any web UI that allows to resolve simple rename/rename conflicts, it is easily conceivable how to implement such a thing. When that happens, we will need to be able to teach the server-side code to discern between the cases that can be handled in the web UI (trivial merge conflicts, trivial rename/rename conflicts) as compared to scenarios where the conflicts are just too complex. Here's an excerpt from t4301: -- snip -- Auto-merging greeting CONFLICT (content): Merge conflict in greeting Auto-merging numbers CONFLICT (file/directory): directory in the way of whatever from side1; moving it to whatever~side1 instead. CONFLICT (modify/delete): whatever~side1 deleted in side2 and modified in side1. Version side1 of whatever~side1 left in tree. -- snap -- This is the complete set of messages provided in the `test conflict notices and such` test case. I immediately notice that every line contains at least one file name. Looking at https://github.com/git/git/blob/v2.35.1/merge-ort.c#L1899, it does not seem as if the file names are quoted: path_msg(opt, path, 1, _("Auto-merging %s"), path); (where `path` is used verbatim in a call to `merge_3way()` before that, i.e. it must not have been quoted) I would like to register a wish to ensure that file names with special characters (such as most notably line-feed characters) are quoted in these messages, so that a simple server-side parser can handle messages starting with `Auto-merging` and with `CONFLICT (content): Merge conflict in `, and "throw the hands up in the air" if any other message prefix is seen. Do you think we can switch to `sq_quote_buf_pretty()` for these messages? For the `Auto-merging` one, it would be trivial, but I fear that we will have to work a bit on the `path_msg()` function (https://github.com/git/git/blob/v2.35.1/merge-ort.c#L630-L649) because it accepts a variable list of arguments without any clue whether the arguments refer to paths or not. (And I would be loathe to switch _all_ callers to do the quoting themselves.) I see 28 calls to that function, and at least a couple that pass not only a path but also an OID (e.g. https://github.com/git/git/blob/v2.35.1/merge-ort.c#L1611-L1613). We could of course be sloppy and pass even OIDs through `sq_quote_buf_pretty()` in `path_msg()`, knowing that there won't be any special characters in them, but it gets more complicated e.g. in https://github.com/git/git/blob/v2.35.1/merge-ort.c#L1648-L1651, where we pass an `strbuf` that contains a somewhat free-form commit message. I guess we could still pass those through `sq_quote_buf_pretty()`, even if they are not paths, to ensure that there are no special characters in the machine-parseable lines. What do you think? Ciao, Dscho
