Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> I tend to call things either content-based conflicts or path-based >> conflicts, where content-based usually means textual-based but also >> includes merges of binaries. > > I like "content-based conflicts". Yup, even before ort existed, we had clear distinction between tree level merges (i.e. which path corresponds to which other path, which is done in unpack_trees() and "read-tree O A B") and content level merges (which is done with ll_merge()). >> Switching to single quoting paths as a matter of style might make >> sense, but only if we go through and change every caller to do so so >> that we can make sure it applies to all paths. And only paths and not >> OIDs. > > Yes, that sounds unappealing. > >> But I'm going to reserve the right in merge-ort to modify, add, or >> delete any of those messages passed to path_msg(), which might wreak >> havoc on your attempts to parse those strings. I think they're a bad >> form for communicating information to a script or program, and trying >> to transform them into such risks making them suboptimal at >> communicating info to humans. These messages should optimize the >> latter, and if we want something for the former, it should probably be >> a new independent bit of info. > > Makes sense. As long as it is made clear that the path_msg() is not for machine consumption (perhaps we can sprinkle <RED><RESET> at random places to make it impossible for machines to handle), I think the direction makes sense, too ;-)
