Re: Please pull mergetool.git

"Theodore Ts'o" [off-list ref] writes:

Please pull from the "mergetool" branch at:
	git://repo.or.cz/git/mergetool.git mergetool

It adds support for vimdiff/gvimdiff as a mergetool program, as well
Josh's suggestion of making the default merge-tool selection more
intelligent, although I've rewritten it somewhat take into account the
comments made by you and others on the git mailing list.

(Note that as of this writing, meld is a pretty sad/dificient tool, and
even GNOME users may very well prefer kdiff3 over meld --- which is my
default.  Still, it seems reasonable to default to using KDE tools in an
KDE login session, and GNOME tools in a GNOME login session, and people
who care differently should set their own preferences in ~/.gitconfig.)

Thanks for keeping track of the mergetool.

I do not see problems in the mergetool part, other than that I
mildly suspect that opendiff -- actually FileMerge -- might want
to be in the test -n "$DISPLAY" section, but that is inherited
from the previous iteration so in that sense leaving outside is
a sane thing to do.

Dan McGee (1):
      git-mergetool: Allow gvimdiff to be used as a mergetool

Theodore Ts'o (2):
      git-mergetool: Make default selection of merge-tool more intelligent
      Add git-applymbox, git-applypatch, and *~ to .gitignore

But I hope you would not be offended if I said I do not want to.

This is not such a strong objection, but I really wish that you
did not mix in the .gitignore change; it does not belong to this
"series".

If it were an obvious and universally nondisagreeable fix, I
would not mind you mixing it in this mergetool updates, but I am
of two minds about the .gitignore change, and actually slightly
in favor of not adding git-applymbox and git-applypatch back.

About git-applymbox and git-applypatch, it helps people when
they switch branches and/or bisect to keep potential build
products from older/different revisions listed in .gitignore.
That would however imply we would end up carrying old entries
forever in it.  We do not keep clean rule in Makefile to remove
build products from older/different revisions when remove build
targets, so why should we keep them in .gitignore?

Also I deliberately have kept *~ out of .gitignore for a reason.
I do have that entry in .git/info/exclude, but the choice of
Emacs over vi is personal to me.

On Sun, Jun 10, 2007 at 12:55:13PM -0700, Junio C Hamano wrote:

But I hope you would not be offended if I said I do not want to.

This is not such a strong objection, but I really wish that you
did not mix in the .gitignore change; it does not belong to this
"series".

OK, no problem.  It was something I noticed while I was preparing the
series, and I thought it was non-controverisal enough to just throw it
in.  It's at the tail of the series, so it's easy enough for me to do a 

	git reset --hard HEAD^

on the mergetool branch....   OK, done.  If you pull from 

        git://repo.or.cz/git/mergetool.git mergetool

You'll only get the first two changes to git-mergetool, and the
.gitignore change has been dropped.

Regards,

					- Ted

On Jun 10, 2007, at 3:55 PM, Junio C Hamano wrote:

I do not see problems in the mergetool part, other than that I
mildly suspect that opendiff -- actually FileMerge -- might want
to be in the test -n "$DISPLAY" section, but that is inherited
from the previous iteration so in that sense leaving outside is
a sane thing to do.

Actually, opendiff (as FileMerge.app) is available under OS X, where  
$DISPLAY is not set.

~~ Brian