Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views

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

 



Seth House wrote:
> To rephrase: I don't wish to spend any more of my time debating
> `mergetool.autoMerge`
> vs.
> `mergetool.autoMerge || mergetool.$tool.autoMerge`
> and I appreciate that others on this list have joined that debate.

> I think all the angles and opinions have been covered at this point so
> perhaps the time has come for a vote or for an executive decision.

I disagree. It's fine if you don't want to participate, but the fact
remains that the position that some tools would want to turn this off
hasn't been properly defended.

> The task of re-reviewing all the mergetools surveyed in the original
> blog post is now complete. I took the opportunity to update most of the
> original post to reflect the discussion and audience here.
> 
> https://www.eseth.org/2020/mergetools.html

Thanks for doing this, but unfortunately one of the most popular isn't
listed there: vimdiff2.

> The "Mergetools Comparison" section is long and is not very easy to read
> with the current layout. Sorry. I wanted to get this published quickly
> and I'll try to clean it up and add a proper TOC. For now, watch out for
> the "Summary" under each tool.
> 
> tl;dr: I didn't see any noteworthy problems with any tool. Mostly
> positive results and some no-impact results.

That's what I expected.

> The two minor impacts were from the two tools that make use of LOCAL
> and REMOTE as historical references; I think those are safe to ignore
> because one is mine and the other builds on mine. All the other
> surveyed tools that reference older versions of the conflicted file
> appear to actively query the Git repository to obtain that info.

In both you say "identical output". The only "adverse effects" are in
the secondary view, which you didn't present.

Can you show these "adverse effects"?

> I'd still like to add more tools and do deeper dives with some of the
> tools already surveyed so suggestions, feedback, and criticisms are very
> welcome. That said, I am now feeling comfortable about adding this to
> Git and defaulting it to enabled. :D

Cool.

Fortunately in the unlikely situation that somebody manages to find a
tool with adverse effects they can just disable the flag.

Cheers.

-- 
Felipe Contreras



[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