On Sun, Jul 29, 2007 at 11:05:42AM +0200, David Kastrup wrote: > Theodore Tso <tytso@xxxxxxx> writes: > > > So I really am beginning to think the right answer is to give up on > > using git-mergetool to support anything other than basic emacs users > > (who just use emacs as an editor, what a concept), > > In contrast, you are trying to support only people by using Emacs > _not_ as an editor, but as a mergetool under the control of git. > That's a mistake. The whole *point* of git-mergetool is to automatically call merge tools so you can do three-way merges under the control of git. If you just want an *editor* then you can just edit the files that are listed as being in conflict after a failed merge or after running "git status". You can do that today without using git-mergetool at all! > Sorry, but you are way off here. The normal, standard use of Emacs is > to start it once and do everything in it. Its startup time is such > that other uses are not feasible. Huh? The startup time of running emacs for me is well under a second (and I have a 20k ~/.emacs.el file that loads a number of other files). I'm sure if you put enough *crap* into your .emacs.el file, you can make it take a huge amount of time, but I suspect your idea of what is "normal" for emacs is more than a little skewed. > So git's mergetool philosophy is currently _straight_ set against the > way Emacs is designed to work. So don't use git-mergetool. Like I said, I suspect the right answer is contrib/git-mergetool.el, and do everything inside emacs. If you are as extreme as someone who pulls in gazillions of emacs packages, and you are using emacs as a desktop, a shell, and a window manager, then you can probably do much better using a pure emacs lisp merge system. Git mergetool is fundamentally designed to work with tools like meld, kdiff3, xxdiff, tkdiff, etc. These are all merge tools, and they work a certain way. They expect, and need, to be driven a certain way. If you insist on following a fundamentally different paradigm, then past a certain point git-mergetool is not going to make you happy no matter what I can do. The point is, git-mergetool does *need* to do know when you are done doing a merge, and it needs to know if you've decided to abandon a merge. Right now ediff doesn't fit well into that paradigm. And that's fundamentally ediff's fault; we can do some kludgery on the git-mergetool side, but the end result will always be unsatisfactory, and will require that the person using it to *know* that it is done. I, personally, don't feel like trying to twist git-mergetool into doing the right thing depending on whether you have emacs21, emacs22, emacs23-snapshot, whether or not the desktop package is in use, whether or not the user is using emacsclient or not, yadda, yadda, yaddda. If you want to take a crack at doing *all* of that mess, and provide a complete solution, send me patches and I'll look at them. I think it will add a huge amount of *crap* into git-mergetool in order to support all possible use cases (I'm not interesting in putting in hackery just for your favorite use case, if it causes other users to scratch their heads in befuddlement and confusion), but feel free to prove me wrong. As someone who has used emacs for over two decades, and have written very sophisticated emacs lisp code during nearly all of those 21 years (1986--2007; my first use of emacs was on a Vax 750 running BSD 4.3 --- if you want to talk about emacs taking a long time to start up, I remember what it was like 20 years ago), I'm pretty well aware of what you can and can not do in emacs, and I think I can say with fairly good authority that for the amount of effort it would take to try to get git-mergetool to hack around all of these different cases, writing git-mergetool.el will probably be easier, and result in a cleaner, better integration with people who like to live their entire lives in a single emacs session. - 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
