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

Re: Conflict editing

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Mar 5, 2007, 04:48 UTC
Message-ID
<46a038f90703042048m42ec07f6yab41c2a2de410ac9@mail.gmail.com>
In-Reply-To
<20070305040406.GB26781@thunk.org>
On 3/5/07, Theodore Tso <tytso@mit.edu> wrote:
Show 10 quoted lines
> On Mon, Mar 05, 2007 at 10:59:33AM +1300, Martin Langhoff wrote:
> > I find xxdiff much better than meld, tkdiff and kdiff -- but maybe I
> > just don't know how to use them, or they have gotten better in the
> > last few months.
>
> I wasn't familiar with xxdiff until just now, but having played with
> it, kdiff3 is much easier for a beginner to use.  The toolbar makes it
> a lot easier to select from one or the other, I find the keyboard
> accellerators to be much more intuitive (although I suppose if you are
> a vi or nethack fan the H, J, K keys will make sense to you :-).

No, I hate that navigation. But arrow keys and pageup/down work great for me. Mouse navigation is superb too.

> In addition, with xxdiff it gives the user way too many options about
> whether you want to save the left, right, or center, or merged
> windows.

I can understand that. But it also does in-the-line diff colouring that I haven't seen the others do. Where the lines don't match on something small, you can see the offending characters in a slightly different tone (I'm colourblind, so I'm unsure of the exact colour, but it does work).

I find xxdiff to be an order of magnitude faster than meld and kdiff3. And at least kdiff3 spews garbage about trying to start the whole of KDE infrastructure hairball so it messes up my terminal where I had interesting messages from the just-executed git-pull.

So at least for now xxdiff is my well-behaved, flexible and fast tool ;-)

And I can see at a glance that single quotes got replaced with double quotes or a trailing space got added or trimmed and _that_'s why the thing didn't merge cleanly.

Show 6 quoted lines
> > One thing I _don't_ want as a user is to see the graphical mergers
> > starting by default. Most merges are trivial, and I can just edit them
> > in emacs or vi.
>
> Well, git will handle most merges automatially for you anyway.  You
> would only use git mergetool to handle the merge conflicts.

Sorry -- I meant to say most conflicts are trivial. Someone mentioned auto-running gui tools on any conflict, and don't think I want that.

cheers,
martin
Previous: Theodore TsoNext: Shawn O. Pearce
Message 6 of 11 in “Conflict editing”
  1. Johannes SchindelinMar 4, 2007
  2. Johannes SchindelinMar 4, 2007
  3. Theodore TsoMar 4, 2007
  4. Martin LanghoffMar 4, 2007
  5. Theodore TsoMar 5, 2007
  6. Martin LanghoffMar 5, 2007
  7. Shawn O. PearceMar 4, 2007
  8. Brian GernhardtMar 5, 2007
  9. Johannes SchindelinMar 5, 2007
  10. Uwe Kleine-KönigMar 5, 2007
  11. Brian GernhardtMar 5, 2007

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.