Re: Conflict editing

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

 



On 3/5/07, Theodore Tso <tytso@xxxxxxx> wrote:
It currently uses a hard-wired preference order for the GUI merge
tools, based on the current functionality of said merge tools, but the
plan is to add options parsing and a config option to allow a
user-specified override.

Any comments, suggestions?

I find xxdiff much better than meld, tkdiff and kdiff -- but maybe I
just don't know how to use them, or they have gotten better in the
last few months.

I had written (and posted) a git-xxdiff earlier. A (minor) concern is
that from a packaging and dependencies perspective, the packager has
to suggest *all* of them, and still a default install may not work at
all -- it might be a good idea to suggest what to install in the error
message. Or depend on all of them (yuck!).

One thing I _don't_ want as a user is to see the graphical mergers
starting by default. Most merges are trivial, and I can just edit them
in emacs or vi.

And when a merge is really hard, and calls for merge-centric tools, I
open gitk alongside to see what commits happened on each side.

cheers,


martin
-
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]