On Tue, Jul 03, 2007 at 09:32:34AM +1200, Sam Vilain wrote: > > 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: > > > > Quit this Ediff session? (y or n) > > File /usr/projects/git/test/testfile.c exists, overwrite? (y or n) > > Merge buffer saved in /usr/projects/git/test/testfile.c > > <delay for 3 annoying seconds> > > Merge buffer saved. Now kill the buffer? (y or n) > > Yeah, I normally just save the merged buffer and quit. This skips all that. > > But I will add your little snippet to my .emacs :) You probably don't want to just add that snippet to your .emacs, since it changes the ediff 'quit' command to always cause emacs to immediately exit, and that's probably not the right thing if you are starting ediff from an emacs session. The correct fix would involve stealing code from emerge's emerge-merge-files-command function to parse the arguments from the command-line --- and in fact, probably the simplest way of fixing things for folks would be to write replacement emerge-*-command functions which call ediff after patching the ediff hooks in the emacs-lisp fragment I sent above. In fact, maybe that's the right approach. I don't think we want to ship emacs lisp files which git-mergetool depends upon, but what if we instead ship some emacs lisp code in the contrib directory which a user could slip into their .emacs file which replaces the two emerge-*-command functions which ones that call ediff instead? That way we don't have all of this complexity added into git-mergetool. - Ted - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
