[issue266] Want an integrated way to move existing committed changes to mq control

[Samuel Masham]

Hi Bryan,

On 5/24/06, Bryan O'Sullivan <bos at serpentine.com> wrote:
> Welcome back from wherever you were :-)

Thanks :)

> > > I'd really like to see an mq command to retroactively turn changesets
> > > into patches.
> >
> > ... would you really?
>
> Why, yes :-)

... oh!

> > The patch itself isn't perfect but mostly will do exactly that.
>
> It seems that from the description of your test case that you can qpop
> changesets off the bottom of the stack, thus establishing a new bottom,
> but without any obvious way to prevent this behaviour.

The behavior is dependent on a new flag being passed and a name given
for the "to be created patch".

> This seems highly likely to yield unwanted results, i.e. changes getting
> turned into patches simply by accident.  That strikes me as undesirable.

That would be a bad thing ... but it shouldn't happen.

To help stop this I propose making normal pop fail if the new flag is used.

(... also I think, maybe, just printing a big fat warning and exiting
if not using -f (force)...)

> I think it would make more sense to have retroactive patchification be a
> separate command, as it's logically different enough from a regular qpop
> that the idea of adding a flag to qpop to control this behaviour appears
> somewhat ugly to me.

After thinking about this for a few minutes i still disagree. My point
is that, as well as the function being the same (remove change from
history to patch queue only), this is an possibly dangerous action and
should not be advertised as a feature with a new command etc.

... Also i think that the number of commands should go down not up,

> Thanks for the patch, though.  Would it be much work to split it into a
> separate command and fix the bugs you alluded to?

You would have to convince me first on point. I hope to convince you
that a new command is a "bad" idea...

And the bugs... ah yes.

The issue is that mq uses patches and hg can record a change that
includes info that cant be shown in a patch. eg adding a empty file.

The error should be caught and handled, this is easy if that's the
only change but if its mixed in with other info... I just don't like
the way that's going :)

Samuel