Subject: Re: What's in git.git (stable)

From: Theodore Tso <[email-masked]>
Date: Sun, 29 Jul 2007 12:40:01 -0400

On Sun, Jul 29, 2007 at 11:05:42AM +0200, David Kastrup wrote:
> Theodore Tso <[email-masked]> 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