[PATCH 2 of 2] mq: flag as deprecated

[Augie Fackler]

On Jun 7, 2014, at 6:28 PM, Angel Ezquerra <angel.ezquerra at gmail.com> wrote:

> On Sat, Jun 7, 2014 at 9:54 PM, Augie Fackler <raf at durin42.com> wrote:
>> # HG changeset patch
>> # User Augie Fackler <raf at durin42.com>
>> # Date 1398790621 14400
>> #      Tue Apr 29 12:57:01 2014 -0400
>> # Node ID 639a70111cffe127bbef74d219a4358323f52e1c
>> # Parent  b78de345e00af1f2f2ca88b98eaafe2ae05824c2
>> mq: flag as deprecated
>> 
>> hg config --edit now directs users to 'hg help extensions' to learn
>> more about extensions and see the available ones. Nearly everything
>> that can be done with mq can be done better and more safely using
>> rebase, histedit, and commit --amend. As such, hide mq from new users
>> so they won't accidentally find the glass that's in our sandbox.
> 
> I know that this is something that must (and should!) eventually
> happen, but IMHO from the perspective of the TortoiseHg users (those
> that rarely if ever see the command line mercurial interface) I don't
> think we are ready to deprecate mq.

Maybe so, but if we're not marking mq as deprecated then I'm not at all comfortable directing new users to 'hg help extensions' when it will list mq somewhat obviously. I think I might have a goal for 3.2 for myself: no reason for any new user to ever consider mq.

> The TortoiseHg history editing workflow is still very much mq-based.
> TortoiseHg supports "commit --amend" but that does not fully match
> what you can do with QRefresh (you cannot easily remove files from a
> commit with "hg commit --amend", for example). I have not used
> histedit much myself but it does not seem very "GUI friendly" (because
> it is basically a really good text-based UI).

Would it help if there was an 'hg record --amend' interface? I'd love to iterate on things to the point that we could also not point tortoise users at mq if at all possible.

> We could possibly put
> some GUI on top of it but since evolve is the future I guess it would
> make more sense for us to improve our evolve support (and this is
> something that we are hoping to do during the next sprint).

I consider evolve and histedit to be complementary. histedit will use evolution, but evolution won't ever (I think) be able to replace histedit's workflow for command-line users.

Note that some sort of histedit-driven drag-and-drop UI for rearranging history would be *totally* awesome. MacHg did something along these lines I think, and there's some extra support in histedit (the --commands flag) to try and make that easier to integrate into a UI.


> Of course TortoiseHg users are unlikely to see the a deprecation
> message (unless mq is removed at some point from the mercurial
> releases) so perhaps this is not a big deal anyway…

There won't be a deprecation beyond what you see here - if you look at 'hg help mq' (or an equivalent), you'll see the deprecation, but mq isn't ever going away because of our backwards compatibility requirements. Does that make you feel better at all?

> 
> Cheers,
> 
> Angel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140607/e0fffa7d/attachment.pgp>