mercurial: Re: mercurial: Mercurial and diff tools

[Matt Mackall]

On Tue, 2010-04-27 at 13:11 -0700, Greg Lindahl wrote:
> On Tue, Apr 27, 2010 at 03:05:59PM -0500, Matt Mackall wrote:
> 
> > If we allow users to globally and by default do magical non-diff diffs
> > with commands generating diffs, then they'll start sending people
> > nonsense patches and breaking workflows that expect actual diffs.
> 
> Which brings us back to the "mechanism, not policy" topic.

Bah. Mercurial is not a tool for working in a vacuum. Policies that let
people work together are a legitimate concern. Diff/patch is a standard.
In fact, it's about the only standard in all of version control, so I
take it kind of seriously[1]. It's understood by people, tools, build
frameworks, howtos, websites, and manuals. If someone decides they're
going to get all colorized-xml-git-diff-by-default just because he can,
he's going to break his project team's makefiles, break his IDE, break
export/import, make all the advice about how to use hg diff/export in
books and howtos useless, waste other people's time with weird patches
no one else can apply, and tarnish Mercurial's just-works reputation.

Extdiff, however, is great. No one expects it to do anything standard.
Adding merge-tools-like configuration to extdiff is also great. Adding
extdiff off-by-default optional support to other commands is reasonable
too. Changing diff's defaults though is not great.

[1] The job I had when I started working on Mercurial was at a Perforce
shop. Perforce outputs non-patch-compatible diffs by default, something
that had me cursing all of 3 minutes into working with it. We did not
get along well. 

-- 
http://selenic.com : development and support for Mercurial and Linux