en/remerge-diff (was: Opinions on merging questions (Was: What's cooking in git.git (Feb 2022, #01; Thu, 3)))

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 4, 2022, 11:20 UTC
Message-ID: <220204.86czk250zv.gmgdl@evledraar.gmail.com>
In-Reply-To: <20220204081336.3194538-1-newren@gmail.com>

On Fri, Feb 04 2022, Elijah Newren wrote:

Show 28 quoted lines

> On Fri, Feb 3, 2022 at 21:22 PM Junio C Hamano <gitster@pobox.com> wrote:
> [...]
>> * en/remerge-diff (2022-02-02) 11 commits
>>  - diff-merges: avoid history simplifications when diffing merges
>>  - merge-ort: mark conflict/warning messages from inner merges as omittable
>>  - show, log: include conflict/warning messages in --remerge-diff headers
>>  - diff: add ability to insert additional headers for paths
>>  - merge-ort: format messages slightly different for use in headers
>>  - merge-ort: mark a few more conflict messages as omittable
>>  - merge-ort: capture and print ll-merge warnings in our preferred fashion
>>  - ll-merge: make callers responsible for showing warnings
>>  - log: clean unneeded objects during `log --remerge-diff`
>>  - show, log: provide a --remerge-diff capability
>>  - Merge branch 'ns/tmp-objdir' into en/remerge-diff
>>  (this branch is used by en/merge-tree.)
>> 
>>  "git log --remerge-diff" shows the difference from mechanical merge
>>  result and the merge result that is actually recorded.
>> 
>>  Will merge to 'next'?
>>  source: <pull.1103.v5.git.1643769457.gitgitgadget@gmail.com>
>
> Ævar's recent opinion on the state of the series was "I think this is
> way past good enough."[*].  He's the only reviewer that has commented
> since December, leading me to believe the half-dozen or so other
> earlier reviewers since August are content with the current shape.
>
> [*] https://lore.kernel.org/git/220202.868rut8qkf.gmgdl@evledraar.gmail.com/

Yes, I'd really like to have this merged down. I didn't comment on your v4/v5 re-rolls but everything there looks good to me and addresses any outstanding comments I had (to the extent that they needed to be addressed at all).

In particular the small addition to the docs to give us a way out out if we need to improve this in combination with other options is good, and much better than my proposed (and more verbose) version.

Thanks!