{"thread":{"id":"8769","subject":"[PATCH] git-mergetool: add support for ediff","startedAt":"2007-06-29T01:00:16Z","lastAt":"2007-07-29T08:54:01Z","messageCount":18,"participants":["Sam Vilain","Jason Sewall","Theodore Tso","Junio C Hamano","David Kastrup"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"46013","messageId":"11830788163411-git-send-email-sam.vilain@catalyst.net.nz","threadId":"8769","inReplyTo":null,"subject":"[PATCH] git-mergetool: add support for ediff","fromName":"Sam Vilain","fromEmail":"sam.vilain@catalyst.net.nz","sentAt":"2007-06-29T01:00:16Z","receivedAt":"2007-06-29T01:00:16Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"There was emerge already but I much prefer this mode.\n\nSigned-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>\n---\n Documentation/config.txt        |    3 ++-\n Documentation/git-mergetool.txt |    3 ++-\n git-mergetool.sh                |   19 ++++++++++++++-----\n 3 files changed, 18 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 50503e8..4661e24 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -550,7 +550,8 @@ merge.summary::\n merge.tool::\n \tControls which merge resolution program is used by\n \tgitlink:git-mergetool[l].  Valid values are: \"kdiff3\", \"tkdiff\",\n-\t\"meld\", \"xxdiff\", \"emerge\", \"vimdiff\", \"gvimdiff\", and \"opendiff\".\n+\t\"meld\", \"xxdiff\", \"emerge\", \"ediff\", \"vimdiff\", \"gvimdiff\", and\n+\t\"opendiff\".\n \n merge.verbosity::\n \tControls the amount of output shown by the recursive merge\ndiff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt\nindex 6c32c6d..1efe6e4 100644\n--- a/Documentation/git-mergetool.txt\n+++ b/Documentation/git-mergetool.txt\n@@ -25,7 +25,8 @@ OPTIONS\n -t or --tool=<tool>::\n \tUse the merge resolution program specified by <tool>.\n \tValid merge tools are:\n-\tkdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, and opendiff\n+\tkdiff3, tkdiff, meld, xxdiff, emerge, ediff, vimdiff, gvimdiff,\n+\tand opendiff\n +\n If a merge resolution program is not specified, 'git mergetool'\n will use the configuration variable merge.tool.  If the\ndiff --git a/git-mergetool.sh b/git-mergetool.sh\nindex 7b66309..6fda8af 100755\n--- a/git-mergetool.sh\n+++ b/git-mergetool.sh\n@@ -258,6 +258,15 @@ merge_file () {\n \t    status=$?\n \t    save_backup\n \t    ;;\n+\tediff)\n+\t    if base_present ; then\n+\t\temacs --eval \"(ediff-merge-files-with-ancestor \\\"$LOCAL\\\" \\\"$REMOTE\\\" \\\"$BASE\\\" nil \\\"$path\\\")\"\n+\t    else\n+\t\temacs --eval \"(ediff-merge-files \\\"$LOCAL\\\" \\\"$REMOTE\\\" nil \\\"$path\\\")\"\n+\t    fi\n+\t    status=$?\n+\t    save_backup\n+\t    ;;\n     esac\n     if test \"$status\" -ne 0; then\n \techo \"merge of $path failed\" 1>&2\n@@ -299,7 +308,7 @@ done\n if test -z \"$merge_tool\"; then\n     merge_tool=`git-config merge.tool`\n     case \"$merge_tool\" in\n-\tkdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | \"\")\n+\tkdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | ediff | vimdiff | gvimdiff | \"\")\n \t    ;; # happy\n \t*)\n \t    echo >&2 \"git config option merge.tool set to unknown tool: $merge_tool\"\n@@ -320,15 +329,15 @@ if test -z \"$merge_tool\" ; then\n         fi\n     fi\n     if echo \"${VISUAL:-$EDITOR}\" | grep 'emacs' > /dev/null 2>&1; then\n-        merge_tool_candidates=\"$merge_tool_candidates emerge\"\n+        merge_tool_candidates=\"$merge_tool_candidates emerge ediff\"\n     fi\n     if echo \"${VISUAL:-$EDITOR}\" | grep 'vim' > /dev/null 2>&1; then\n         merge_tool_candidates=\"$merge_tool_candidates vimdiff\"\n     fi\n-    merge_tool_candidates=\"$merge_tool_candidates opendiff emerge vimdiff\"\n+    merge_tool_candidates=\"$merge_tool_candidates opendiff ediff emerge vimdiff\"\n     echo \"merge tool candidates: $merge_tool_candidates\"\n     for i in $merge_tool_candidates; do\n-        if test $i = emerge ; then\n+        if test $i = emerge || test $i = ediff ; then\n             cmd=emacs\n         else\n             cmd=$i\n@@ -351,7 +360,7 @@ case \"$merge_tool\" in\n \t    exit 1\n \tfi\n \t;;\n-    emerge)\n+    emerge|ediff)\n \tif ! type \"emacs\" > /dev/null 2>&1; then\n \t    echo \"Emacs is not available\"\n \t    exit 1\n-- \n1.5.2.1.1131.g3b90\n"},{"id":"46015","messageId":"31e9dd080706281831vbe24597i9b6a5f6f6db6fec8@mail.gmail.com","threadId":"8769","inReplyTo":"11830788163411-git-send-email-sam.vilain@catalyst.net.nz","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Jason Sewall","fromEmail":"jasonsewall@gmail.com","sentAt":"2007-06-29T01:31:50Z","receivedAt":"2007-06-29T01:31:50Z","isPatch":true,"sender":{"key":"jasonsewall@gmail.com","avatar":null},"body":"On 6/28/07, Sam Vilain <sam.vilain@catalyst.net.nz> wrote:\n> There was emerge already but I much prefer this mode.\n>\n\nI beat ya to it: http://marc.info/?l=git&m=118301192520295&w=2\n\nBut it looks like maybe you did a better job (updated docs, for\nexample). Other than that, it's almost exactly the same.\n\nAck.\n\nJason\n\nP.S.\n\ndoing this:\n>      if echo \"${VISUAL:-$EDITOR}\" | grep 'emacs' > /dev/null 2>&1; then\n>         merge_tool_candidates=\"$merge_tool_candidates emerge ediff\"\n>      fi\n\nand then this\n\n>     merge_tool_candidates=\"$merge_tool_candidates opendiff ediff emerge vimdiff\"\n\nmakes this\n\n>      echo \"merge tool candidates: $merge_tool_candidates\"\n\nprint out emerge and ediff twice, presumably because we're adding it\nin for both \"visual\" emacs and \"regular\" (i.e. -nw) emacs. I suck at\nshell scripts, so I'm probably missing something but what why do we\nhave all of that testing for emacs + vim if we just add their tools\nanyway right afterwards?\n"},{"id":"46018","messageId":"20070629040328.GG29279@thunk.org","threadId":"8769","inReplyTo":"31e9dd080706281831vbe24597i9b6a5f6f6db6fec8@mail.gmail.com","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-06-29T04:03:28Z","receivedAt":"2007-06-29T04:03:28Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jun 28, 2007 at 06:31:50PM -0700, Jason Sewall wrote:\n> >     echo \"merge tool candidates: $merge_tool_candidates\"\n\nThis was a debugging echo that slipped by; I had never intended for it\nto be kept.\n\n> print out emerge and ediff twice, presumably because we're adding it\n> in for both \"visual\" emacs and \"regular\" (i.e. -nw) emacs. I suck at\n> shell scripts, so I'm probably missing something but what why do we\n> have all of that testing for emacs + vim if we just add their tools\n> anyway right afterwards?\n\nSome things get added twice but in a different order because the\nsearch order matters.  But in terms of adding emerge and ediff, yes,\nthere's no point, since they always get added in the same order.  \n\nI'll have to look at the two and see why people like one over the\nother, and then we'll have to pick which one should be the default.\nAlthough as I've said, past a certain point people should just put\ntheir personal preference in .gitconfig.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"46207","messageId":"20070702020401.GD28917@thunk.org","threadId":"8769","inReplyTo":"20070629040328.GG29279@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-02T02:04:01Z","receivedAt":"2007-07-02T02:04:01Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Jun 29, 2007 at 12:03:28AM -0400, Theodore Tso wrote:\n> I'll have to look at the two and see why people like one over the\n> other, and then we'll have to pick which one should be the default.\n> Although as I've said, past a certain point people should just put\n> their personal preference in .gitconfig.\n\nAfter looking at ediff, it is definitely the more polished and\nfeatureful compared to emerge --- except in one critical area, which\nis calling as a mergeing tool from a shell script or command line.\nEdiff fundamentally assumes that it fired off from inside an emacs\nenvironment, whereas emerge is much friendly as an external merge\nprogram. \n\nThis can be shown in the relatively easy way emerge can be run from\nthe command-line:\n\n\temacs -f emerge-files-with-ancestor-command \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$path\"\n\n... where as with ediff, you have to run it this way:\n\n\temacs --eval \"(ediff-merge-files-with-ancestor \\\"$LOCAL\\\" \\\"$REMOTE\\\" \\\"$BASE\\\" nil \\\"$path\\\")\"\n\nUnfortunately, it's not enough.  Ediff doesn't have an \"abort\" command\nwhich returns a non-zero exit status, and when you use the \"quit\"\ncommand, it asks you a series of obnoxious questions:\n\nQuit this Ediff session? (y or n)\nFile /usr/projects/git/test/testfile.c exists, overwrite? (y or n)\nMerge buffer saved in /usr/projects/git/test/testfile.c\n<delay for 3 annoying seconds>\nMerge buffer saved.  Now kill the buffer? (y or n)\n\n... and then it leaves you in the emacs window, and you have to type\n^X^C by hand.\n\nSo while ediff is more featureful, its integration is so lacking that\nit is incredibly annoying to use.\n\nWhich leaves us with the interesting question.  We could just\nintegrate it, but not make it the default (the above makes ediff just\nfar too annoying for a user who is not expecting it).  \n\nAlternatively, we could patch around the problem.  The following emacs\nlisp code fixes the ediff issues:\n\n(defun ediff-write-merge-buffer ()\n  (let ((file ediff-merge-store-file))\n    (set-buffer ediff-buffer-C)\n    (write-region (point-min) (point-max) file)\n    (message \"Merge buffer saved in: %s\" file)\n    (set-buffer-modified-p nil)\n    (sit-for 1)))\n\n(setq ediff-quit-hook 'kill-emacs\n      ediff-quit-merge-hook 'ediff-write-merge-buffer)\n\nBut the only clean way of adding that to git-mergetool would be something like this:\n\n\temacs --eval \"(progn (defun ediff-write-merge-buffer () (let ((file ediff-merge-store-file)) (set-buffer ediff-buffer-C) (write-region (point-min) (point-max) file) (message \\\"Merge buffer saved in: %s\\\" file) (set-buffer-modified-p nil) (sit-for 1))) (setq ediff-quit-hook 'kill-emacs ediff-quit-merge-hook 'ediff-write-merge-buffer) (ediff-merge-files-with-ancestor \\\"$LOCAL\\\" \\\"$REMOTE\\\" \\\"$BASE\\\" nil \\\"$path\\\")\"\n\nBut that seems too ugly to live, and it could break in the future if\nediff ever changes some of its internal variables.\n\n\nAlternatively, we could file a bug report with the ediff folks, and\nrequest that they add an 'ediff-files-with-ancestor-command and\n'ediff-files-command just as emerge does.  The problem with that\napproach is that ediff is shipped with emacs, and emacs has a release\ncycle measured in **years**.\n\n\nSo my current thinking is that ediff will *not* be the default for\ngit-mergetool if emacs is present, and that emerge will be used for\nnow, because of these problems.\n\nComments?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"46208","messageId":"7v1wfr1qn8.fsf@assigned-by-dhcp.cox.net","threadId":"8769","inReplyTo":"20070702020401.GD28917@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-02T02:32:59Z","receivedAt":"2007-07-02T02:32:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> Unfortunately, it's not enough.  Ediff doesn't have an \"abort\" command\n> which returns a non-zero exit status, and when you use the \"quit\"\n> command, it asks you a series of obnoxious questions:\n>\n> ...\n> Alternatively, we could patch around the problem.  The following emacs\n> lisp code fixes the ediff issues:\n\nBut that would be changing the behaviour globally, and not\nlimited to the particular session invoked from git-mergetool,\nwouldn't it?  If that is the case it would be a hard sell to\nEmacs users, especially the ones that keep their Emacs running\nforever and have emacsclient as their EDITOR, I would think.\n"},{"id":"46209","messageId":"20070702030521.GA4798@thunk.org","threadId":"8769","inReplyTo":"7v1wfr1qn8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-02T03:05:21Z","receivedAt":"2007-07-02T03:05:21Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Jul 01, 2007 at 07:32:59PM -0700, Junio C Hamano wrote:\n> Theodore Tso <tytso@mit.edu> writes:\n> \n> > Unfortunately, it's not enough.  Ediff doesn't have an \"abort\" command\n> > which returns a non-zero exit status, and when you use the \"quit\"\n> > command, it asks you a series of obnoxious questions:\n> >\n> > ...\n> > Alternatively, we could patch around the problem.  The following emacs\n> > lisp code fixes the ediff issues:\n> \n> But that would be changing the behaviour globally, and not\n> limited to the particular session invoked from git-mergetool,\n> wouldn't it?  If that is the case it would be a hard sell to\n> Emacs users, especially the ones that keep their Emacs running\n> forever and have emacsclient as their EDITOR, I would think.\n\nThe emacs lisp code I gave there was the minimal necessary so it\ncould be passed on the command-line; I was trying to keep it small.\n\nObviously, the patch that would have to get sent to the ediff folks\nwould have to be much more generalized --- in fact, probably the right\nthing to do is to send a full patch that actually implemented\nediff-merge-files-command and ediff-merge-files-with-ancestoers-commands.\n\nAs far as people using emacsclient as their editor, it would be simple\nenough to have the emacs lisp code test to see if\nserver-buffer-clients is non-nill; if it is, then we know that this\nmerge request was trigered by emacsclient, and so (server-done) should\nbe called instead of (kill-emacs).  Emerge does not do this; arguably\nthis is a bug in emerge.\n\nThe other way we could deal with this problem is to fire up a separate\nemacs even if EDITOR is emacsclient, on the theory that\nEDITOR=emacsclient meants that the user prefers emacs, but it doesn't\nnecessarily mean that we have to *use* emacsclient, especially when\nemerge currently doesn't DTRT with emacsclient.\n\nOne thing that did cross my mind is that we could put code which\npatched ediff.el and emerge.el in /usr/share/git/lisp/... and then\npassed called emacs with something like this \"emacs -l\n$sharedir/lisp/ediff-patches.el ...\".  But this implies packaging\nemacs lisp files with git, and I'm not at ALL sure we want to go\nthere.  Personally, I still like kdiff3 as my personal favorite\nmergetool, and given that emacs starts up pretty fast these days, I've\ngiven up on emacsclient, but I know there are certainly people who use\nthem.\n\n(Mmmm...., I just pulled down an early emacs 23 snapshot with Xft\nsupport enabled, so I can enjoy the anti-aliased font goodness.  Even\nwith all of the Gtk and Xft bloat, the emacs 23 snapshot is still\nquick snappy to fire up.)\n\n\t\t\t\t\t- Ted\n"},{"id":"46215","messageId":"7vr6nrz9yx.fsf@assigned-by-dhcp.cox.net","threadId":"8769","inReplyTo":"20070702030521.GA4798@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-02T04:49:10Z","receivedAt":"2007-07-02T04:49:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> One thing that did cross my mind is that we could put code which\n> patched ediff.el and emerge.el in /usr/share/git/lisp/... and then\n> passed called emacs with something like this \"emacs -l\n> $sharedir/lisp/ediff-patches.el ...\".  But this implies packaging\n> emacs lisp files with git, and I'm not at ALL sure we want to go\n> there. ...\n\nI hope not.\n\n> ...  Personally, I still like kdiff3 as my personal favorite\n> mergetool, and given that emacs starts up pretty fast these days, I've\n> given up on emacsclient, but I know there are certainly people who use\n> them.\n\nThe reason I personally use emacsclient is not about the\nstart-up delay, but with the access to existing buffers,\nkeyboard macros, Gnus buffers, ... IOW the access to the\n\"session\" while editing.  I suspect people with long running\nEmacs session use emacsclient for that reason.\n"},{"id":"46244","messageId":"20070702144800.GA4720@thunk.org","threadId":"8769","inReplyTo":"7vr6nrz9yx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-02T14:48:00Z","receivedAt":"2007-07-02T14:48:00Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Jul 01, 2007 at 09:49:10PM -0700, Junio C Hamano wrote:\n> The reason I personally use emacsclient is not about the\n> start-up delay, but with the access to existing buffers,\n> keyboard macros, Gnus buffers, ... IOW the access to the\n> \"session\" while editing.  I suspect people with long running\n> Emacs session use emacsclient for that reason.\n\nSure, but do you need access to existing buffers, keyboard, macros,\netc., if you're simply firing up an emacs to handle a merge conflict?\nIf the goal is just to run a merge application, then firing up a\nseparate process makes a lot more sense.\n\nOne other thing which I just noticed is that emacs21's emacsclient\ndoes NOT support the -f or -e option.  And a lot of people may still\nbe using emacs21.  So in any case, at the moment we are in fact using\nto fire up a separate process when using emerge or ediff.  I suppose\nwe could try testing to see if the user is running emacs21 or emacs22\nif EDITOR==emacsclient, but there's no easy way of doing this short of\ndoing something heavyweight such as firing up emacs and asking to eval\nsome lisp that prints the value of emacs-version to stdout.  And even\nthen we would have to fix emerge to do the right thing when invoked\nvia emacsclient.  Yuck...\n\nThis still leaves us with the question about whether the following to\nfix ediff is acceptable:\n\n   \t  emacs --eval \"(progn (defun ediff-write-merge-buffer () (let ((file ediff-merge-store-file)) (set-buffer ediff-buffer-C) (write-region (point-min) (point-max) file) (message \\\"Merge buffer saved in: %s\\\" file) (set-buffer-modified-p nil) (sit-for 1))) (setq ediff-quit-hook 'kill-emacs ediff-quit-merge-hook 'ediff-write-merge-buffer) (ediff-merge-files-with-ancestor \\\"$LOCAL\\\" \\\"$REMOTE\\\" \\\"$BASE\\\" nil \\\"$path\\\"))\"\n\nIn my mind it's on the hairy edge. Alternatively we just never use\nediff by default, and assume that either expert users can hack their\n.emacs.el file to have the right overrides will use ediff, or who are\nwilling to put up with ediff's user-hostile approach to quitting an\nmerge session.\n\n\t\t\t\t\t\t -  Ted\n"},{"id":"46282","messageId":"46896EF2.70006@vilain.net","threadId":"8769","inReplyTo":"20070702020401.GD28917@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-07-02T21:32:34Z","receivedAt":"2007-07-02T21:32:34Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Theodore Tso wrote:\n> After looking at ediff, it is definitely the more polished and\n> featureful compared to emerge --- except in one critical area, which\n> is calling as a mergeing tool from a shell script or command line.\n  [...]\n> \temacs --eval \"(ediff-merge-files-with-ancestor \\\"$LOCAL\\\" \\\"$REMOTE\\\" \\\"$BASE\\\" nil \\\"$path\\\")\"\n> \n> Unfortunately, it's not enough.  Ediff doesn't have an \"abort\" command\n> which returns a non-zero exit status, and when you use the \"quit\"\n> command, it asks you a series of obnoxious questions:\n> \n> Quit this Ediff session? (y or n)\n> File /usr/projects/git/test/testfile.c exists, overwrite? (y or n)\n> Merge buffer saved in /usr/projects/git/test/testfile.c\n> <delay for 3 annoying seconds>\n> Merge buffer saved.  Now kill the buffer? (y or n)\n\nYeah, I normally just save the merged buffer and quit.  This skips all that.\n\nBut I will add your little snippet to my .emacs :)\n\nSam.\n"},{"id":"46286","messageId":"20070702215859.GA20597@thunk.org","threadId":"8769","inReplyTo":"46896EF2.70006@vilain.net","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-02T21:58:59Z","receivedAt":"2007-07-02T21:58:59Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Jul 03, 2007 at 09:32:34AM +1200, Sam Vilain wrote:\n> > Unfortunately, it's not enough.  Ediff doesn't have an \"abort\" command\n> > which returns a non-zero exit status, and when you use the \"quit\"\n> > command, it asks you a series of obnoxious questions:\n> > \n> > Quit this Ediff session? (y or n)\n> > File /usr/projects/git/test/testfile.c exists, overwrite? (y or n)\n> > Merge buffer saved in /usr/projects/git/test/testfile.c\n> > <delay for 3 annoying seconds>\n> > Merge buffer saved.  Now kill the buffer? (y or n)\n> \n> Yeah, I normally just save the merged buffer and quit.  This skips all that.\n> \n> But I will add your little snippet to my .emacs :)\n\nYou probably don't want to just add that snippet to your .emacs, since\nit changes the ediff 'quit' command to always cause emacs to\nimmediately exit, and that's probably not the right thing if you are\nstarting ediff from an emacs session.\n\nThe correct fix would involve stealing code from emerge's\nemerge-merge-files-command function to parse the arguments from the\ncommand-line --- and in fact, probably the simplest way of fixing\nthings for folks would be to write replacement emerge-*-command\nfunctions which call ediff after patching the ediff hooks in the\nemacs-lisp fragment I sent above.\n\nIn fact, maybe that's the right approach.  I don't think we want to\nship emacs lisp files which git-mergetool depends upon, but what if we\ninstead ship some emacs lisp code in the contrib directory which a\nuser could slip into their .emacs file which replaces the two\nemerge-*-command functions which ones that call ediff instead?\n\nThat way we don't have all of this complexity added into git-mergetool.\n\n\t\t \t   \t      \t   - Ted\n"},{"id":"46288","messageId":"20070702221639.GB20597@thunk.org","threadId":"8769","inReplyTo":"20070702215859.GA20597@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-02T22:16:39Z","receivedAt":"2007-07-02T22:16:39Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"OK, so I've hacked together the following emacs-lisp snippet, which I\npropose would go in contrib/use-ediff-instead.el.  If placed in your\n.emacs.el file, it will cause you to use ediff instead of emerge when\nyou call \"git mergetool\".  It does so by replacing the two functions\nemerge-files-command and emerge-files-with-ancestor-comand with ones\nthat patch the necessary ediff hooks, and then calling the ediff\npackage instead of the emerge package.\n\nWith this .el file, no changes are needed to git-mergetool.sh.  Does\nthis meet your needs?\n\n\t\t\t\t\t- Ted\n\n;; use-ediff-instead.el\n;;\n;; This emacs lisp snippet should be placed in your .emacs.el file in\n;; order to use the ediff package instead of emerge for git-mergetool.\n;; Ediff has more whiz-bang features, but unfortunately it doesn't\n;; integrate well with shell scripts that try to invoke ediff from an\n;; emacs shell invocation.\n\n(defun ediff-write-merge-buffer ()\n  (let ((file ediff-merge-store-file))\n    (set-buffer ediff-buffer-C)\n    (write-region (point-min) (point-max) file)\n    (message \"Merge buffer saved in: %s\" file)\n    (set-buffer-modified-p nil)\n    (sit-for 1)))\n\n(defun emerge-files-command ()\n  (let ((file-a (nth 0 command-line-args-left))\n\t(file-b (nth 1 command-line-args-left))\n\t(file-out (nth 2 command-line-args-left)))\n    (setq command-line-args-left (nthcdr 3 command-line-args-left))\n    (setq ediff-quit-hook 'kill-emacs\n\t  ediff-quit-merge-hook 'ediff-write-merge-buffer)\n    (ediff-merge-files file-a file-b  nil file-out)))\n\n(defun emerge-files-with-ancestor-command ()\n  (let (file-a file-b file-anc file-out)\n    ;; check for a -a flag, for filemerge compatibility\n    (if (string= (car command-line-args-left) \"-a\")\n\t;; arguments are \"-a ancestor file-a file-b file-out\"\n\t(progn\n\t  (setq file-a (nth 2 command-line-args-left))\n\t  (setq file-b (nth 3 command-line-args-left))\n\t  (setq file-anc (nth 1 command-line-args-left))\n\t  (setq file-out (nth 4 command-line-args-left))\n\t  (setq command-line-args-left (nthcdr 5 command-line-args-left)))\n        ;; arguments are \"file-a file-b ancestor file-out\"\n        (setq file-a (nth 0 command-line-args-left))\n        (setq file-b (nth 1 command-line-args-left))\n        (setq file-anc (nth 2 command-line-args-left))\n        (setq file-out (nth 3 command-line-args-left))\n        (setq command-line-args-left (nthcdr 4 command-line-args-left)))\n    (setq ediff-quit-hook 'kill-emacs\n\t  ediff-quit-merge-hook 'ediff-write-merge-buffer)\n    (ediff-merge-files-with-ancestor file-a file-b file-anc nil file-out)))\n\n;; End of use-ediff-instead.el\n"},{"id":"46297","messageId":"7vwsxiwgdj.fsf@assigned-by-dhcp.cox.net","threadId":"8769","inReplyTo":"20070702144800.GA4720@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-02T23:11:20Z","receivedAt":"2007-07-02T23:11:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> On Sun, Jul 01, 2007 at 09:49:10PM -0700, Junio C Hamano wrote:\n>> The reason I personally use emacsclient is not about the\n>> start-up delay, but with the access to existing buffers,\n>> keyboard macros, Gnus buffers, ... IOW the access to the\n>> \"session\" while editing.  I suspect people with long running\n>> Emacs session use emacsclient for that reason.\n>\n> Sure, but do you need access to existing buffers, keyboard, macros,\n> etc., if you're simply firing up an emacs to handle a merge conflict?\n>\n> If the goal is just to run a merge application, then firing up a\n> separate process makes a lot more sense.\n\nExisting buffers may help somewhat as I am likely to have that\nalready loaded, but other than that probably not.\n\n> In my mind it's on the hairy edge. Alternatively we just never use\n> ediff by default, and assume that either expert users can hack their\n> .emacs.el file to have the right overrides will use ediff, or who are\n> willing to put up with ediff's user-hostile approach to quitting an\n> merge session.\n\nI think that is sane.\n"},{"id":"46300","messageId":"46898815.6030607@vilain.net","threadId":"8769","inReplyTo":"20070702221639.GB20597@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-07-02T23:19:49Z","receivedAt":"2007-07-02T23:19:49Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Theodore Tso wrote:\n> OK, so I've hacked together the following emacs-lisp snippet, which I\n> propose would go in contrib/use-ediff-instead.el.  If placed in your\n> .emacs.el file, it will cause you to use ediff instead of emerge when\n> you call \"git mergetool\".  It does so by replacing the two functions\n> emerge-files-command and emerge-files-with-ancestor-comand with ones\n> that patch the necessary ediff hooks, and then calling the ediff\n> package instead of the emerge package.\n> \n> With this .el file, no changes are needed to git-mergetool.sh.  Does\n> this meet your needs?\n> \n> \t\t\t\t\t- Ted\n> \n> ;; use-ediff-instead.el\n [...]\n\nThanks for that, it mostly works, however it doesn't seem to notice if I\nabort without making the merge complete (on emacs21).  In my smartmerge\nscript (http://utsl.gen.nz/scripts/smartmerge) I detect this condition\nbased on the presence of merge markers, possibly dubious but pragmatic.\n\nI still don't really understand why having to save the merged buffer and\nexit is such a huge issue.  Already I have to select \"-t emerge\" to get\nemerge.  I would have thought it would be better to just make the other\nmode available, and let the user figure it out.\n\nSam.\n"},{"id":"46309","messageId":"20070703010955.GA5322@thunk.org","threadId":"8769","inReplyTo":"46898815.6030607@vilain.net","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-03T01:09:55Z","receivedAt":"2007-07-03T01:09:55Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Jul 03, 2007 at 11:19:49AM +1200, Sam Vilain wrote:\n> Thanks for that, it mostly works, however it doesn't seem to notice if I\n> abort without making the merge complete (on emacs21).  In my smartmerge\n> script (http://utsl.gen.nz/scripts/smartmerge) I detect this condition\n> based on the presence of merge markers, possibly dubious but pragmatic.\n\nHmm, well, here's a way of fixing it.  (See attached, below.)  It adds\na new command 'x', which when you hit it in the ediff control window,\nexits with a error status of '1', indicating that the merge has\nfailed.  This is something which emerge, kdiff3, tkdiff, et. al all\nsupport; but which ediff doesn't.\n\n> I still don't really understand why having to save the merged buffer and\n> exit is such a huge issue.  Already I have to select \"-t emerge\" to get\n> emerge.  I would have thought it would be better to just make the other\n> mode available, and let the user figure it out.\n\nI'm just exploring alternatives.  Basically, it just seems interesting\nthat ediff has a lot of nice features, but also has some incredibly\nuser-hostile features.  The first time I tried using ediff, I indeed\ntried saving the buffer and exiting it.  That's when I discovered that\nafter I changed the focus to the merge window and saved it, when I\ntried typing ^X^C, the exit failed with the error message \"Attempt to\ndelete a surrogate minibuffer frame\".  That's the sort of thing that\nwill cause non-elisp programmers to run screaming off into the\ndistance.\n\nSo if you are going to save the merge the buffer and exit, you *have*\nto use the 'q' command, and endure the loads of stupid questions\nissued by ediff, OR, you can discover that ^X^C in the ediff control\nwindow doesn't actually cause emacs to exit, but it does make the\nediff control window go away.  (Which is another insane bit of ediff's\nUI design... why should ^X^C do something completely different in the\nediff control window?!?)\n\nSo yeah, we can add ediff as an optional support that people have to\nexplicitly request, but quite frankly, having played with it, I don't\nknow why anyone would use it without a huge number of fix ups, which\nis why I was trying to make ediff actually be usable for someone who\ndoesn't mind typing ^X^C twice, for no good reason, after figuring out\nthat this illogical thing is what you actually need to do to exit\nediff.  (I actually read the help text first, so I got treated to the\nreally annoying ediff-quit behavior before I figured out the double\n^X^C trick.)\n\n\t\t\t\t\t\t- Ted\n\n;; use-ediff-instead.el\n;;\n;; This emacs lisp snippet should be placed in your .emacs.el file in\n;; order to use the ediff package instead of emerge for git-mergetool.\n;; Ediff has more whiz-bang features, but unfortunately it doesn't\n;; integrate well with shell scripts that try to invoke ediff from an\n;; emacs shell invocation.  This script tries to address these problems.\n\n(defun ediff-write-merge-buffer ()\n  (let ((file ediff-merge-store-file))\n    (set-buffer ediff-buffer-C)\n    (write-region (point-min) (point-max) file)\n    (message \"Merge buffer saved in: %s\" file)\n    (set-buffer-modified-p nil)\n    (sit-for 1)))\n\n(defun ediff-abort ()\n  \"Abort the ediff session without a non-zero exit status\"\n  (interactive)\n  (kill-emacs 1))\n\n(defun ediff-setup-abort ()\n  (define-key ediff-mode-map \"x\" 'ediff-abort))\n\n(defun emerge-files-command ()\n  (let ((file-a (nth 0 command-line-args-left))\n\t(file-b (nth 1 command-line-args-left))\n\t(file-out (nth 2 command-line-args-left)))\n    (setq command-line-args-left (nthcdr 3 command-line-args-left))\n    (setq ediff-quit-hook 'kill-emacs\n\t  ediff-quit-merge-hook 'ediff-write-merge-buffer\n\t  ediff-keymap-setup-hook 'ediff-setup-abort)\n    (ediff-merge-files file-a file-b  nil file-out)))\n\n(defun emerge-files-with-ancestor-command ()\n  (let (file-a file-b file-anc file-out)\n    ;; check for a -a flag, for filemerge compatibility\n    (if (string= (car command-line-args-left) \"-a\")\n\t;; arguments are \"-a ancestor file-a file-b file-out\"\n\t(progn\n\t  (setq file-a (nth 2 command-line-args-left))\n\t  (setq file-b (nth 3 command-line-args-left))\n\t  (setq file-anc (nth 1 command-line-args-left))\n\t  (setq file-out (nth 4 command-line-args-left))\n\t  (setq command-line-args-left (nthcdr 5 command-line-args-left)))\n        ;; arguments are \"file-a file-b ancestor file-out\"\n        (setq file-a (nth 0 command-line-args-left))\n        (setq file-b (nth 1 command-line-args-left))\n        (setq file-anc (nth 2 command-line-args-left))\n        (setq file-out (nth 3 command-line-args-left))\n        (setq command-line-args-left (nthcdr 4 command-line-args-left)))\n    (setq ediff-quit-hook 'kill-emacs\n\t  ediff-quit-merge-hook 'ediff-write-merge-buffer\n\t  ediff-keymap-setup-hook 'ediff-setup-abort)\n    (ediff-merge-files-with-ancestor file-a file-b file-anc nil file-out)))\n\n;; End of use-ediff-instead.el\n"},{"id":"46335","messageId":"4689EC38.1010603@vilain.net","threadId":"8769","inReplyTo":"20070703010955.GA5322@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-07-03T06:27:04Z","receivedAt":"2007-07-03T06:27:04Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Theodore Tso wrote:\n> I'm just exploring alternatives.  Basically, it just seems interesting\n> that ediff has a lot of nice features, but also has some incredibly\n> user-hostile features.  The first time I tried using ediff, I indeed\n> tried saving the buffer and exiting it.  That's when I discovered that\n> after I changed the focus to the merge window and saved it, when I\n> tried typing ^X^C, the exit failed with the error message \"Attempt to\n> delete a surrogate minibuffer frame\".  That's the sort of thing that\n> will cause non-elisp programmers to run screaming off into the\n> distance.\n\nOuch.  Yes, I've never seen that before and no doubt if I had've I'd\nfeel the same way.  I just save the merge buffer and quit, and it is\npretty obedient for me.\n\nHowever I guess it wouldn't be nice to have a merge mode that did not\nwork out of the box for a large number of users.\n\nYour .el file certainly does the trick for me - I reckon throw it in\ncontrib/\n\nSam.\n"},{"id":"48890","messageId":"85hcno287w.fsf@lola.goethe.zz","threadId":"8769","inReplyTo":"20070703010955.GA5322@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-28T09:22:43Z","receivedAt":"2007-07-28T09:22:43Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\n[Picking up an old thread]\n\nTheodore Tso <tytso@mit.edu> writes:\n\n> On Tue, Jul 03, 2007 at 11:19:49AM +1200, Sam Vilain wrote:\n>\n> Hmm, well, here's a way of fixing it.  (See attached, below.)  It\n> adds a new command 'x', which when you hit it in the ediff control\n> window, exits with a error status of '1', indicating that the merge\n> has failed.  This is something which emerge, kdiff3, tkdiff, et. al\n> all support; but which ediff doesn't.\n>\n>> I still don't really understand why having to save the merged buffer and\n>> exit is such a huge issue.  Already I have to select \"-t emerge\" to get\n>> emerge.  I would have thought it would be better to just make the other\n>> mode available, and let the user figure it out.\n>\n> I'm just exploring alternatives.  Basically, it just seems\n> interesting that ediff has a lot of nice features, but also has some\n> incredibly user-hostile features.  The first time I tried using\n> ediff, I indeed tried saving the buffer and exiting it.  That's when\n> I discovered that after I changed the focus to the merge window and\n> saved it, when I tried typing ^X^C, the exit failed with the error\n> message \"Attempt to delete a surrogate minibuffer frame\".  That's\n> the sort of thing that will cause non-elisp programmers to run\n> screaming off into the distance.\n\nTed, I think you are somewhat missing the main audience here.  The\nmain audience are people who actually _use_ Emacs, and those will be\ncomfortable with the concept \"save to have changes persist, don't save\nif you don't want changes to persist, exit using C-x # or C-x C-c as\nappropriate\".  Basically, it would appear that you try figuring out\nhow to make ediff appeal to non-Emacs users.  But those would not have\nemacs/emacsclient in their EDITOR variable in the first place.\n\nI have been bitten by mergetool calling emacs rather than emacsclient,\nresulting in a non-working merge (since the default directory was set\ndifferently from what the call expected due to my use of the desktop\npackage), and mergetool afterwards assuming that the not-even-started\nmerge was successful.  A royal nuisance, and completely unworkable.\n\nWhile it may be nice to have some Lisp preparation for people who\ndon't want to touch or learn Emacs _except_ for using it for merging\nin git, I think we should first cater to people actually using Emacs\nalready.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48948","messageId":"20070729023854.GA17204@thunk.org","threadId":"8769","inReplyTo":"85hcno287w.fsf@lola.goethe.zz","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-29T02:38:54Z","receivedAt":"2007-07-29T02:38:54Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Jul 28, 2007 at 11:22:43AM +0200, David Kastrup wrote:\n> Ted, I think you are somewhat missing the main audience here.  The\n> main audience are people who actually _use_ Emacs, and those will be\n> comfortable with the concept \"save to have changes persist, don't save\n> if you don't want changes to persist, exit using C-x # or C-x C-c as\n> appropriate\".  Basically, it would appear that you try figuring out\n> how to make ediff appeal to non-Emacs users.  But those would not have\n> emacs/emacsclient in their EDITOR variable in the first place.\n> \n> I have been bitten by mergetool calling emacs rather than emacsclient,\n> resulting in a non-working merge (since the default directory was set\n> differently from what the call expected due to my use of the desktop\n> package), and mergetool afterwards assuming that the not-even-started\n> merge was successful.  A royal nuisance, and completely unworkable.\n\nEmacsclient is a completely different problem, or at least adds a\nwhole new dimention, compared to the ediff/emerge issue.  You can't\nrun either emerge or ediff using the emacsclient in emacs21, since it\nlacks support for either the -e or the -f command-line option.  All\nyou can do in emacs21 when using eamcsclient is to request emacs to\nedit a file.  \n\nOne of the problems with emacs is that it is so customizable that\npeople can set up emacs in such a way that different ways of launching\nemacs may lead to surprises, thanks to their .emacs21.  This makes\nsupporting emacs based merging clients to be highly problematic.  Use\nof the desktop package is one way in which things can be quite\nsurprising.  Worse yet, the desktop package is only in emacs22 and up.\n(And emacs 22 was *just* released, not all that long ago; many people\nmay still be using emacs21).  So if we use emacs --no-desktop to\ndisable the desktop package, it will cause emacs21 to complain about\nan unknown option.  Joy.  Which means that to avoid running into\nproblems with emacs22 users who are using the desktop package,\ngit-mergetool is going to have to find out in advance whether emacs21\nor emacs22 (or an emacs development 23.0.0 snapshot) is in use; on a\ndebian system you can have 3 or 4 emacs installed simultaneously.  What fun.\n\nIn any case, the main issue is that there is an emerging (sorry)\nstandard about how merge tools are supposed to work, in terms of being\nable to support 2-way or 3-way merges, about being able to specify\nwhich file (and which file only, in the best case) should be used as\nthe output file as the result of the merge, and about how tools can\nsignal either a successful merge, or a request by the user to abort\nthe merge becuase things didn't work out for one reason or another.\n\nThe problem is that ediff doesn't really fit this model.  For people\nwho really want to live their life in emacs, and using emacs as their\ndesktop (not for me, but maybe for some folks), maybe it would be\nbetter for those folks to simply build a git-mergetool.el that ran\n100% in emacs, instead of trying to shift back and forth between the\ncommand-line and emacs, would make everyone happier.  Right now\ngit-mergetool needs to ask questions about the disposition of\nsymlinks, permission changes, etc.  If it is done as a\ngit-mergetool.el which is tied into git.el and ediff, it could be a\nlot more seamless.\n\n> While it may be nice to have some Lisp preparation for people who\n> don't want to touch or learn Emacs _except_ for using it for merging\n> in git, I think we should first cater to people actually using Emacs\n> already.\n\nCatering to the hard-core Emacs folks is *hard*.  I knew someone who\nhad PDP-10 assembly language in their .emacs.el file, and one day his\ncustom emacs extension worked again when he started playing with the\nKLH10 PDP-10 emulator, and reused his .emacs.el startup file there....\nOf course, at some level folks like that will always need to fend for\nthemselves.\n\nAs I said earlier, I don't have a huge objection to support ediff in\nsome degraded mode (I think the UI is ghastly bad), if users\nexplicitly request it, but I would *not* want to make it the default\nand spring it on some unsuspecting user.  Quite frankly, right now the\nKDE and GNOME tools are way better either emerge or ediff, so they are\nonly really useful as a default in the terminal-only case.\n\n     \t    \t      \t\t       - Ted\n"},{"id":"48967","messageId":"85myxfzj2u.fsf@lola.goethe.zz","threadId":"8769","inReplyTo":"20070729023854.GA17204@thunk.org","subject":"Re: [PATCH] git-mergetool: add support for ediff","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-29T08:54:01Z","receivedAt":"2007-07-29T08:54:01Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> On Sat, Jul 28, 2007 at 11:22:43AM +0200, David Kastrup wrote:\n\n>> Ted, I think you are somewhat missing the main audience here.  The\n>> main audience are people who actually _use_ Emacs, and those will\n>> be comfortable with the concept \"save to have changes persist,\n>> don't save if you don't want changes to persist, exit using C-x #\n>> or C-x C-c as appropriate\".  Basically, it would appear that you\n>> try figuring out how to make ediff appeal to non-Emacs users.  But\n>> those would not have emacs/emacsclient in their EDITOR variable in\n>> the first place.\n>> \n>> I have been bitten by mergetool calling emacs rather than\n>> emacsclient, resulting in a non-working merge (since the default\n>> directory was set differently from what the call expected due to my\n>> use of the desktop package), and mergetool afterwards assuming that\n>> the not-even-started merge was successful.  A royal nuisance, and\n>> completely unworkable.\n>\n> Emacsclient is a completely different problem, or at least adds a\n> whole new dimention, compared to the ediff/emerge issue.  You can't\n> run either emerge or ediff using the emacsclient in emacs21, since\n> it lacks support for either the -e or the -f command-line option.\n\nIf the user asks for it, we should try giving it to him.  If\nEmacsclient bombs out because of a non-understood option, one can\nstill fall back to calling a separate Emacs.\n\n> All you can do in emacs21 when using eamcsclient is to request emacs\n> to edit a file.\n\nYes, but emacsclient --version returns a version string, and\nemacsclient will exit with an error if it can't get to understand the\ncommand line options or to talk with Emacs.  So there are reasonably\nways to notice when to fallback.\n\n> One of the problems with emacs is that it is so customizable that\n> people can set up emacs in such a way that different ways of\n> launching emacs may lead to surprises, thanks to their .emacs21.\n> This makes supporting emacs based merging clients to be highly\n> problematic.  Use of the desktop package is one way in which things\n> can be quite surprising.  Worse yet, the desktop package is only in\n> emacs22 and up.\n\nThe desktop package has already been in Emacs 21, so it is not exactly\na new problem but has been round for more than 7 years.\n\n> (And emacs 22 was *just* released, not all that long ago; many\n> people may still be using emacs21).  So if we use emacs --no-desktop\n> to disable the desktop package, it will cause emacs21 to complain\n> about an unknown option.  Joy.\n\nCorrect: the --no-desktop option is new.\n\n> Which means that to avoid running into problems with emacs22 users\n> who are using the desktop package, git-mergetool is going to have to\n> find out in advance whether emacs21 or emacs22 (or an emacs\n> development 23.0.0 snapshot) is in use; on a debian system you can\n> have 3 or 4 emacs installed simultaneously.  What fun.\n\n$EDITOR --version\n\n> In any case, the main issue is that there is an emerging (sorry)\n> standard about how merge tools are supposed to work, in terms of\n> being able to support 2-way or 3-way merges, about being able to\n> specify which file (and which file only, in the best case) should be\n> used as the output file as the result of the merge, and about how\n> tools can signal either a successful merge, or a request by the user\n> to abort the merge becuase things didn't work out for one reason or\n> another.\n>\n> The problem is that ediff doesn't really fit this model.\n\nEmacs is an editor.  If we can't make an editor fit into merge\nresolution, we have a design problem.  It is a matter of convenience\nthat the editor is called with some initial files and something like\nediff-whatever, but the end result clearly should be that the user\nwrites the file if he wants changes to persist, and doesn't if\ndoesn't.\n\n> For people who really want to live their life in emacs, and using\n> emacs as their desktop (not for me, but maybe for some folks), maybe\n> it would be better for those folks to simply build a\n> git-mergetool.el that ran 100% in emacs, instead of trying to shift\n> back and forth between the command-line and emacs, would make\n> everyone happier.  Right now git-mergetool needs to ask questions\n> about the disposition of symlinks, permission changes, etc.  If it\n> is done as a git-mergetool.el which is tied into git.el and ediff,\n> it could be a lot more seamless.\n\nBut this is no reason not to fix the currently broken behavior.  If\nyou insist that \"emerge\" or \"ediff\" is _not_ to be used as an editor,\nbut rather as a special-purpose mergetool for the sake of git, then\nthe only logical conclusion can be to call it with \"-q\", bypassing any\nuser initialization.\n\nI believe this would be a mistake at least when $EDITOR points to\nEmacs, because this means the user is used to using Emacs/Emacsclient\nas _editor_, and anything else would be _confusing_.\n\n>> While it may be nice to have some Lisp preparation for people who\n>> don't want to touch or learn Emacs _except_ for using it for\n>> merging in git, I think we should first cater to people actually\n>> using Emacs already.\n>\n> Catering to the hard-core Emacs folks is *hard*.\n\nSaving a desktop session is not hard-core.  Using emacsclient is not\nhard-core.  Those are standard, basic, use cases.\n\n> I knew someone who had PDP-10 assembly language in their .emacs.el\n> file, and one day his custom emacs extension worked again when he\n> started playing with the KLH10 PDP-10 emulator, and reused his\n> .emacs.el startup file there....\n\nCan we get another strawman a bit closer to the main road, please?\n\n> Of course, at some level folks like that will always need to fend\n> for themselves.\n\nYes.  I am not talking about people breaking things by code of their\nown.  I am talking about a _standard_ setup being broken by git.\n\n> As I said earlier, I don't have a huge objection to support ediff in\n> some degraded mode (I think the UI is ghastly bad), if users\n> explicitly request it, but I would *not* want to make it the default\n> and spring it on some unsuspecting user.  Quite frankly, right now\n> the KDE and GNOME tools are way better either emerge or ediff, so\n> they are only really useful as a default in the terminal-only case.\n\nAgain, you fall into the trap of not allowing others to have a life\nand Emacs outside of git's preconceptions.  emerge and ediff might be\nworse for people who would not use Emacs for anything but merging.\nBut one advantage of Emacs is that I can look at all sorts of other\nfiles and buffers and information sources _while_ I am merging, and\ndeclare the merge finished when _I_ want it (signaled by exiting\neither Emacs or Emacsclient), not when some arbitrary command thinks\nit finished.\n\nEmacs is one of the most flexible tools ever.  Disallowing any editing\nuse not foreseen and sanctioned by git-mergetool is _always_ going to\nlead to trouble.  If you do _anything_ like this, you _must_ call\nEmacs -q in order to omit _any_ user initializations you did not\nforesee.  But this will also kill user-specific major modes which he\nmight want to use for visualizing files.  It will be less onerous than\nhaving all hell break lose because you can't cater for even standard\ninitializations or setup, but it will still be a nuisance.\n\nSo please don't try crippling Emacs into a git-only tool.  Call it\nwith the files in question, give it an appropriate initial command to\nwork with if possible, and leave the rest to the user.  He will save\nand finish, or not save and finish, which is the way of an editor to\ncommunicate with its environment.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"}]}