[PATCH 2 of 2] mq: flag as deprecated

[Angel Ezquerra]

On Sun, Jun 8, 2014 at 1:02 AM, Augie Fackler <raf at durin42.com> wrote:
>
> 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.

That's an ambitious and noble goal :-)

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

I have never used hg record myself. Looking at its help it also seems
very command line oriented, so I don't know how that would help. What
did you have in mind?

Evolve has an uncommit command. However I believe that it creates a
new successor changeset. From the point of view of a GUI user that is
amending a revision by editing some files and perhaps removing some
other files it would be reasonable to expect that only one new
obsolete revision (the original revision) and only one new successor
would be created (since the user just clicked on a single, amend,
button). If we used a combination of hg uncommit and hg commit --amend
to do what qrefresh does then we would be creating at least two new
obsolete revisions. I think this would be confusing (when reviewing
the hidden history).

I would prefer if there were a switch that let you get a more qrefresh
like behavior when doing commit --amend or perhaps that let you
directly pass a list of files to remove from the commit.

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

Is that because histedit lets you plan several steps in one go?

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

I agree. Ever since I started looking into evolve and how we might
integrate it into TortoiseHg I've had the feeling in order to support
something akin to our current drag and drop based mq workflow we will
not be able just naively convert every drag and drop operation into
the corresponding evolve commands. If we did so we would end up with
tones of unnecessary obsolete revisions and hg evolve calls and a very
hard to understand obsolete history.

The good thing about our current MQ workflow is that it is "modal".
You can only drag and drop unapplied patches, and the new patch order
only matters when you (try to) apply those reordered patches. This is
not possible (I think) with plain evolve. Perhaps histedit is the
solution?

Anyway, if I make it to the sprint I would love to discuss this...

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

Yes it does :-)

Cheers,

Angel