[PATCH] rebase: don't fail when pulling applied patches (issue1622)

[Matt Mackall]

On Tue, 2011-07-19 at 23:00 +0200, Stefano Tortarolo wrote:
> 2011/7/19 Matt Mackall <mpm at selenic.com>
> >
> > On Mon, 2011-07-18 at 20:29 +0200, Stefano Tortarolo wrote:
> > > # HG changeset patch
> > > # User Stefano Tortarolo <stefano.tortarolo at gmail.com>
> > > # Date 1311013707 -7200
> > > # Node ID 4c4b1e8339c5d6d579244d7dfe15fb5991ca0885
> > > # Parent  647071c6dfcfc19a4dedb37c1e4c0b60378d953b
> > > rebase: don't fail when pulling applied patches (issue1622)
> > >
> > > When mq patches are sent to another repo, applied and then
> > > pulled again, rebase fails with the error:
> > > "abort: cannot delete revision X above applied patches"
> >
> > I don't really understand this description?
> 
> This happens in mq.py when we try to delete/pop intermediate
> patches  (see test-mq-qdelete.t)
> but the message could be improved.
> >From rebase's point of view, this happens when we try to strip.

Uh, what?

I guess I'll go look at the bug report. The original reporter's
description was:

"When a patch is applied remote in the same place as it is in the mq,
then it is not pulled because it is here, but its children are pulled.
It is impossible to qpop the patch. The only thing you can do is
qfinish. pull --rebase does not handle this situation."

..and that makes perfect sense to me. The key things here not mentioned
above is that pull introduces non-mq _children_ of mq csets.

The key thing is that a pull introduces non-mq children of mq
changesets, which isn't mentioned above. 

> > > In this situations, the only reasonable thing to do seems to be
> > > qfinish those patches, rebase and then try to import them
> > > again as mq patches. If this is not possible, it just goes on
> > > and prints something like:
> > > "revision Y cannot be imported again as mq patch"
> >
> > When can this fail?
> 
> Let's say we have this situation (for a more detailed explanation please go
> to issue1622):
> 
> a - b(p) - c(p)
>       \
>        d
> 
> If we rebase c(p) onto d we have to finalize c(p) and b(p), then try to be
> smart and re-import c and b (they were mq patches after all...)
> but now we're in this situation:
>   a - b - d - c'(p)
> and b cannot be an mq patch anymore.

Shouldn't we just refuse to do this?

-- 
Mathematics is the supreme nostalgia of our time.