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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 25, 2022, 18:40 UTC
Message-ID: <xmqqh78mdc31.fsf@gitster.g>
In-Reply-To: <nycvar.QRO.7.76.6.2202251726500.11118@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

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

Show 17 quoted lines

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