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

Re: [PATCH] git-mergetool: add support for ediff

From
Theodore Tso <tytso@mit.edu>
Date
Jul 2, 2007, 03:05 UTC
Message-ID
<20070702030521.GA4798@thunk.org>
In-Reply-To
<7v1wfr1qn8.fsf@assigned-by-dhcp.cox.net>
On Sun, Jul 01, 2007 at 07:32:59PM -0700, Junio C Hamano wrote:
Show 15 quoted lines
> Theodore Tso <tytso@mit.edu> writes:
> 
> > Unfortunately, it's not enough.  Ediff doesn't have an "abort" command
> > which returns a non-zero exit status, and when you use the "quit"
> > command, it asks you a series of obnoxious questions:
> >
> > ...
> > Alternatively, we could patch around the problem.  The following emacs
> > lisp code fixes the ediff issues:
> 
> But that would be changing the behaviour globally, and not
> limited to the particular session invoked from git-mergetool,
> wouldn't it?  If that is the case it would be a hard sell to
> Emacs users, especially the ones that keep their Emacs running
> forever and have emacsclient as their EDITOR, I would think.

The emacs lisp code I gave there was the minimal necessary so it could be passed on the command-line; I was trying to keep it small.

Obviously, the patch that would have to get sent to the ediff folks would have to be much more generalized --- in fact, probably the right thing to do is to send a full patch that actually implemented ediff-merge-files-command and ediff-merge-files-with-ancestoers-commands.

As far as people using emacsclient as their editor, it would be simple enough to have the emacs lisp code test to see if server-buffer-clients is non-nill; if it is, then we know that this merge request was trigered by emacsclient, and so (server-done) should be called instead of (kill-emacs). Emerge does not do this; arguably this is a bug in emerge.

The other way we could deal with this problem is to fire up a separate emacs even if EDITOR is emacsclient, on the theory that EDITOR=emacsclient meants that the user prefers emacs, but it doesn't necessarily mean that we have to *use* emacsclient, especially when emerge currently doesn't DTRT with emacsclient.

One thing that did cross my mind is that we could put code which patched ediff.el and emerge.el in /usr/share/git/lisp/... and then passed called emacs with something like this "emacs -l $sharedir/lisp/ediff-patches.el ...". But this implies packaging emacs lisp files with git, and I'm not at ALL sure we want to go there. Personally, I still like kdiff3 as my personal favorite mergetool, and given that emacs starts up pretty fast these days, I've given up on emacsclient, but I know there are certainly people who use them.

(Mmmm...., I just pulled down an early emacs 23 snapshot with Xft support enabled, so I can enjoy the anti-aliased font goodness. Even with all of the Gtk and Xft bloat, the emacs 23 snapshot is still quick snappy to fire up.)

					- Ted
Previous: Junio C HamanoNext: Junio C Hamano
Message 6 of 18 in “git-mergetool: add support for ediff”
  1. git-mergetool: add support for ediffSam Vilain, Jun 29, 2007
  2. Jason SewallJun 29, 2007
  3. Theodore TsoJun 29, 2007
  4. Theodore TsoJul 2, 2007
  5. Junio C HamanoJul 2, 2007
  6. Theodore TsoJul 2, 2007
  7. Junio C HamanoJul 2, 2007
  8. Theodore TsoJul 2, 2007
  9. Junio C HamanoJul 2, 2007
  10. Sam VilainJul 2, 2007
  11. Theodore TsoJul 2, 2007
  12. Theodore TsoJul 2, 2007
  13. Sam VilainJul 2, 2007
  14. Theodore TsoJul 3, 2007
  15. Sam VilainJul 3, 2007
  16. David KastrupJul 28, 2007
  17. Theodore TsoJul 29, 2007
  18. David KastrupJul 29, 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.