hg equivalent to "bk collapse"?

[Ben Hood]

>
> I'm using MQ to do something similar so far.
>
> For instance, when I'm working on two bugs, which should be resolved in
> the same commit, I make a clone of the repository and start with:
>
>   cd ws/project
>   hg clone trunk gker
>   cd gker
>   hg qinit -c
>   hg qnew -fm '144361 summary of bug 144361' 144361
>   hg qnew -fm '144342 summary of bug 144361' 144342
>
> This lets me work with the two patches as a 'pair', but I can also
> push/pop them at will or even re-order them.
>
> At various times, when I have a 'stable' version of the patches which I
> want to test, I use qcommit to save the patch state:
>
>   hg qcommit -m 'summary of patch state'
>
> When I'm satisfied that it all works, and I want to push the patches
> upstream, I pop them off the tip of the 'gker' repository, and I use 'hg
> import' to make them real changesets on top of the tip.
>
>   hg qpop -a
>   hg import .hg/patches/144361 && hg qdelete 144361
>   hg import .hg/patches/144342 && hg qdelete 144342
>
> Then I can either 'hg push' two changesets, or hg diff with the last
> version of the trunk tip which I pulled and 'import' that diff.

I'm not an exprienced MQ user so this suggestion makes me ask 2 questions:

1. If you were working on a patch to an upstream tree, wouldn't you be
using qrefresh to save the current state of the patch during the time
that you are doing all of your own hacking and debugging? I would have
thought that the end result is one patch without many changelog
entries.

2. Doesn't the hg import at the end imply that you yourself maintain
the upstream tree? If so, then why wouldn't you just be using MQ for
that tree as well? Is there an advantage to importing it into native
mercurial? Or is it so that you can send to another upstream tree that
may not be using MQ?

Thanks,
Ben