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

[Stefano Tortarolo]

2011/7/20 Matt Mackall <mpm at selenic.com>

> 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.


Yes, that's exactly what happens here.



> > > > 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?


I guess it's up to us... We're able to be quite smart.
After all, b is now public (the "remote" cset d starts from it, it must be
"public") so we're
suggesting that it's not possible to convert b to an mq patch unless we
convert also d.
BUT b exists in a remote repo so what's the point in ever trying to modify
that cset?

c, on the other hand, is local and it can still be an mq patch.

Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110720/c595b312/attachment.html>