[PATCH] mq: automatically upgrade to git patch when necessary (issue767)

[Matt Mackall]

On Tue, 2009-12-29 at 21:27 +0100, Thomas Arendsen Hein wrote:
> * Matt Mackall <mpm at selenic.com> [20091229 21:18]:
> > On Tue, 2009-12-29 at 20:59 +0100, Patrick Mezard wrote:
> > > # HG changeset patch
> > > # User Patrick Mezard <pmezard at gmail.com>
> > > # Date 1262113500 -3600
> > > # Node ID 61f7e9239f3b41d6b8e8e1c2858f2309f954f246
> > > # Parent  c7355a0e1f39968ab39a62e9bf059e5129a61497
> > > mq: automatically upgrade to git patch when necessary (issue767)
> > 
> > Hiding in here is most of another oft-requested feature: reporting when
> > normal diff or export commands generate lossy patches. Given that we
> > probably don't want such patches to fail in the middle, I think
> > exceptions are the wrong reporting mechanism to use here.
> > 
> > I'd rather see the loss-detection bits on their own first and some
> > thoughts as to how to implement the lossy patch reporting, followed by
> > the mq-specific bits.
> 
> The 'keep' part (what we're doing now) is special to mq and I can
> imagine that users have no problems with git diffs in mq, but never
> want to export or patchbomb git patches unless they add --git.
> 
> Therefore having a way to override the global behaviour for mq (and
> maybe for other extensions, too) would be nice in any case.
> 
> After experiments within mq have shown that it is good, the
> configuration options could be made available for general diff, too,
> hopefully extended by a "git = warn" and/or "git = abort" feature.
> 
> The underlying mechanism could still be changed without the user
> having to worry about it.

Huh? I'm not talking about options or defaults or even mq at all. I'm
talking about the desire for normal 'hg diff' to warn that a standard
patch is incomplete. Patrick has obviously implemented most of that to
make his mq feature, except not in a way that will actually work for the
'hg diff' issue because it's throwing exceptions. So rather than making
the 'hg diff' thing even harder to do in the future, I'm asking that we
tackle it now.

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