git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] mergetool-lib: add a three-way diff view for vim/gvim

From
Jeff King <peff@peff.net>
Date
Sep 24, 2010, 21:31 UTC
Message-ID
<20100924213116.GA19676@sigill.intra.peff.net>
In-Reply-To
<AANLkTin-BSAFwvuTyJ96BW6MqrKVEni+Af2M0u7WE_yZ@mail.gmail.com>
On Fri, Sep 24, 2010 at 02:01:01PM -0500, Dan McGee wrote:
Show 41 quoted lines
> On Sun, Sep 19, 2010 at 4:48 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > On Sat, Sep 18, 2010 at 10:34 AM, David Aguilar <davvid@gmail.com> wrote:
> >> On Tue, Sep 14, 2010 at 09:21:43PM -0500, Dan McGee wrote:
> >>> When the base version is available, use a three-way, four panel view by
> >>> default. This shows the (local, base, remote) revisions up top and the
> >>> merged result by itself in the lower pane. All revisions will still scroll
> >>> together by default, and the cursor still defaults to the merged result edit
> >>> pane.
> >>>
> >>> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
> >>> ---
> >>>
> >>> Vim was one of the few diff commands to not support a three-way merge showing
> >>> the base revision, so this is a stab at resolving that shortfall. The biggest
> >>> objection I can see to this is making the interface a bit more cumbersome and
> >>> bloated.
> >>>
> >>> An example screenshot of what this produces:
> >>> http://www.toofishes.net/media/extra/vim_three_way.png
> >>>
> >>> -Dan
> >>
> >>
> >> Patch 1/2 of this series looks good to me.
> >>
> >> Is it worth keeping the old behavior and calling this new
> >> mode "vimdiff3" or something along those lines?
> >>
> >> I'm not a vimdiff user so I'm not be the best person to
> >> judge the merits of this change.  I like what it's trying
> >> to accomplish, though.  Are there any vimdiff users
> >> with strong feelings either way?
> >
> > I think this is a definite improvement; the old mode wasn't really
> > useful for me.
> 
> Not as much feedback as I had hoped, but thanks to those that did
> speak up. I was thinking of adding a separate mode, but I think it
> would then get under-used and as I said, every other merge tool was
> already doing this anyway.
A little more feedback:

I use vim but don't use vimdiff, because the original mode seemed useless to me. Your change makes it much better. I haven't actually had to do any merging lately, though, so I can't comment in practice.

Given that nobody has objected, you have a few comments in support, and the fact that it makes it similar to every other mergetool driver, I think it should probably be the default. If somebody really finds it objectionable, it is not hard for them to configure the old behavior.

-Peff
Previous: Dan McGee
Message 10 of 10 in “mergetool-lib: combine vimdiff and gvimdiff run blocks”
  1. 1/2 mergetool-lib: combine vimdiff and gvimdiff run blocksDan McGee, Sep 15, 2010
  2. 2/2 mergetool-lib: add a three-way diff view for vim/gvimDan McGee, Sep 15, 2010
  3. David AguilarSep 18, 2010
  4. Felipe ContrerasSep 19, 2010
  5. Dan McGeeSep 24, 2010
  6. Jacob HelwigSep 24, 2010
  7. Jeff KingSep 24, 2010
  8. David AguilarSep 25, 2010
  9. 2/2 mergetool-lib: add a three-way diff view for vim/gvimDan McGee, Sep 27, 2010
  10. Jeff KingSep 24, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.