Rethinking mq and pbranch now we have rebase

[Matt Mackall]

On Thu, 2009-11-26 at 10:50 +0100, Dirkjan Ochtman wrote:
> On Thu, Nov 26, 2009 at 10:46, Matt Mackall <mpm at selenic.com> wrote:
> > Well mq wasn't invented in a vacuum, it's part of a long line of tools
> > supporting important workflows. In some of these flows, patches (rather
> > than changesets) are first class objects that are maintained for
> > significant periods of time outside of the target project.
> > Backward-compatibility with quilt and rpm's linear model is also quite
> > useful.
> 
> I understand your position on that, but if you want to maintain that,
> I think the argument of not putting something like pbranch in hgext
> because it duplicates mq functionality (I'm not sure if that was the
> exact argument for not including pbranch) doesn't hold.

It's not. I'm certainly open to an mq/pbranch/shelve/attic/record
hybrid. I don't want n slightly different ways of dealing with malleable
history all with different capabilities, I want one. And it needs to be
relatively mq-compatible, which means importing and exporting
quilt-style patch series.

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