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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 04 2022, Elijah Newren wrote:

> On Fri, Feb 3, 2022 at 21:22 PM Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxx>
>
> Æ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@xxxxxxxxxxxxxxxxxxx/

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!




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux