[PATCH 2 of 2] mq: flag as deprecated

[Pierre-Yves David]

On 06/07/2014 05:44 PM, Augie Fackler wrote:
>
> On Jun 7, 2014, at 8:18 PM, Angel Ezquerra <angel.ezquerra at gmail.com> wrote:
>
>> 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'm +1 for this deprecation


>>>>
>>>> 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?
>
> Actually, thinking about this some more, I think what we should do is build an interface I've been wanting for emacs integration for a while: commit-from-patch. Basically, you could do import --dont-change-working-copy on a properly formatted patch, and then you'd be able to select sub-hunk level changes in any kind of GUI for commit. Did that make sense? If not, I want to explain it more so that we can be sure it'd be useful to TortoiseHG.

You have already used crecord right? It seems very close to what you 
describe.


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

Ha! you have been flashed giving too much importance to the hidden 
history at this stage of the implementation!

>> 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.
>
> Yeah, I've wanted something like that in commit, but I'm not good at smart ideas.

Reminder: There is 3 states:

a. `p1(.)` content
b. `.` content
c. working directory content

- `qrefresh` let you choose between `a` and `c` only (much frustration)
- `amend` let you choose between b and c,
- `uncommit` let you choose between a and b,

We can probably add a ``--uncommit PATTERN`` flag to ``hg amend``. This 
would lets one any of `a`, `b` or `c` with a single command

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

"evolution" is a concept. Histedit is a UI. The new UI coming out of 
this evolution concept (lets call it evolve) may grow something 
replacing histedit with a smoother UI for executing a plan of operation.

>> Is that because histedit lets you plan several steps in one go?
>
> Yup. I tend to do a lot of work in the reverse order compared to how it has to be checked in, so I'm often reversing half my history and folding the other half together.
>
>>
>>> 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?

I've already discussed a concept of "planning". This would be a way to 
describe operation that one want to see happening at some point. 
(Probably by invocation of ``hg evolve``?).

This would be something useful to implement a ``hg commit --insert`` 
featured for example.

-- 
Pierre-Yves David