Re: [PATCH 08/12] merge-ort: provide a merge_get_conflicted_files() helper function

Johannes Schindelin [off-list ref] writes:

quoted

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()).

quoted

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.

quoted

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 ;-)