en/remerge-diff [Was: Re: What's cooking in git.git (Sep 2021, #09; Thu, 30)]

From: Elijah Newren <newren@gmail.com>
Date: Oct 1, 2021, 06:31 UTC
Message-ID: <CABPp-BH2C5HFw_=NtK71oNGXkntzcJd2un0TgMb=UnJ5yJxAAA@mail.gmail.com>
In-Reply-To: <xmqqh7e18soj.fsf@gitster.g>

On Thu, Sep 30, 2021 at 6:09 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

>
> * en/remerge-diff (2021-08-31) 7 commits
>  - doc/diff-options: explain the new --remerge-diff option
>  - show, log: provide a --remerge-diff capability
>  - tmp-objdir: new API for creating and removing primary object dirs
>  - merge-ort: capture and print ll-merge warnings in our preferred fashion
>  - ll-merge: add API for capturing warnings in a strbuf instead of stderr
>  - merge-ort: add ability to record conflict messages in a file
>  - merge-ort: mark a few more conflict messages as omittable
>
>  A new presentation for two-parent merge "--remerge-diff" can be
>  used to show the difference between mechanical (and possibly
>  conflicted) merge results and the recorded resolution.
>
>  Will merge to 'next'?

No, please mark it as expecting an update. Peff made multiple good suggestions in his recent review:

  * Modify the ll-merge API to return an enum status instead of
printing warning messages about binary files, and let callers handle
it
  * Replace the new auxiliary files containing conflict messages, with
auxiliary diff headers containing conflict messages
  * Do something different with the tmp-objdir usage or use
pretend_object_file().  I'm slightly worried the latter was only
designed for a few files that all fit into memory, which may not be
valid for this usecase.

And ns/batched-fsync now semantically conflicts slightly in that we both extended the tmp-objdir API in similar but slightly different ways. So that needs to be worked out...