Re: [GIT] Please pull mergetool.git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Theodore Ts'o" <tytso@xxxxxxx> 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.

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux