Patchwork [2,of,2] mq: flag as deprecated

login
register
mail settings
Submitter Augie Fackler
Date June 7, 2014, 7:54 p.m.
Message ID <639a70111cffe127bbef.1402170840@augie-macbookair.laroche.local>
Download mbox | patch
Permalink /patch/4952/
State Deferred
Headers show

Comments

Augie Fackler - June 7, 2014, 7:54 p.m.
# HG changeset patch
# User Augie Fackler <raf@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.
Angel Ezquerra - June 7, 2014, 10:28 p.m.
On Sat, Jun 7, 2014 at 9:54 PM, Augie Fackler <raf@durin42.com> wrote:
> # HG changeset patch
> # User Augie Fackler <raf@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.

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

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

Cheers,

Angel
Augie Fackler - June 7, 2014, 11:02 p.m.
On Jun 7, 2014, at 6:28 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:

> On Sat, Jun 7, 2014 at 9:54 PM, Augie Fackler <raf@durin42.com> wrote:
>> # HG changeset patch
>> # User Augie Fackler <raf@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
Angel Ezquerra - June 8, 2014, 12:18 a.m.
On Sun, Jun 8, 2014 at 1:02 AM, Augie Fackler <raf@durin42.com> wrote:
>
> On Jun 7, 2014, at 6:28 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:
>
>> On Sat, Jun 7, 2014 at 9:54 PM, Augie Fackler <raf@durin42.com> wrote:
>>> # HG changeset patch
>>> # User Augie Fackler <raf@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
Augie Fackler - June 8, 2014, 12:44 a.m.
On Jun 7, 2014, at 8:18 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:

> On Sun, Jun 8, 2014 at 1:02 AM, Augie Fackler <raf@durin42.com> wrote:
>> 
>> On Jun 7, 2014, at 6:28 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:
>> 
>>> On Sat, Jun 7, 2014 at 9:54 PM, Augie Fackler <raf@durin42.com> wrote:
>>>> # HG changeset patch
>>>> # User Augie Fackler <raf@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?

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.

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

Yeah, I've wanted something like that in commit, but I'm not good at smart ideas.

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

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?
> 
> Anyway, if I make it to the sprint I would love to discuss this…

Yes! I'd be delighted. And if you don't make the sprint, we'll schedule some video chats or something and work out a plan.

> 
>>> 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
Pierre-Yves David - June 9, 2014, 4:32 p.m.
On 06/07/2014 05:44 PM, Augie Fackler wrote:
>
> On Jun 7, 2014, at 8:18 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:
>
>> On Sun, Jun 8, 2014 at 1:02 AM, Augie Fackler <raf@durin42.com> wrote:
>>>
>>> On Jun 7, 2014, at 6:28 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:
>>>
>>>> On Sat, Jun 7, 2014 at 9:54 PM, Augie Fackler <raf@durin42.com> wrote:
>>>>> # HG changeset patch
>>>>> # User Augie Fackler <raf@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.
Martin Geisler - June 10, 2014, 8:35 a.m.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> writes:

> On 06/07/2014 05:44 PM, Augie Fackler wrote:
>>
>> On Jun 7, 2014, at 8:18 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:
>>
>>> 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)

I think your assertion that this caused "much frustration" is incorrect.
I don't recall seeing people complain about it, but I do remember seeing
people complain about the different behavior in 'hg commit --amend'.

We've gone over this before :) Almost a year ago:

  http://markmail.org/message/oce4axafrmovsqgu

There, I tried to argue that the 'hg commit --amend -X foo' case is
confusing. I call it confusing since I don't know how to see what the
commit will contain before I made it. It's easy to predict what the
effect of 'hg qrefresh -X foo' is since foo is removed completely.

> - `amend` let you choose between b and c,

The accumulating-only behavior of amend is less than ideal to me since I
I'm often in the case where I want to choose between 'a' 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

That sounds useful. I'm actually surprised that you want to keep the 'hg
amend' command around -- I had somehow assumed that it was a temporary
command and that 'hg commit --amend' would be the normal way to amend
commits. Is the purpose of a dedicated amend command to let people
uncommit files or are there other uses for it?
Pierre-Yves David - July 5, 2014, 9:01 p.m.
On 06/10/2014 10:35 AM, Martin Geisler wrote:
> Pierre-Yves David <pierre-yves.david@ens-lyon.org> writes:
>
>> On 06/07/2014 05:44 PM, Augie Fackler wrote:
>>>
>>> On Jun 7, 2014, at 8:18 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:
>>>
>>>> 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)
>
> I think your assertion that this caused "much frustration" is incorrect.
> I don't recall seeing people complain about it, but I do remember seeing
> people complain about the different behavior in 'hg commit --amend'.

I appreciate your effort to convinces me I do not have first hand 
experience of tens of user complaining about this behavior of MQ. But I 
afraid it is not very successful… (sarcastic way to point you at a 
passive trolling occurrence)

>> - `amend` let you choose between b and c,
>
> The accumulating-only behavior of amend is less than ideal to me since I
> I'm often in the case where I want to choose between 'a' and 'c'.

The absolute only behavior of qrefresh is less than ideal to me since 
I'm often in the case where I want to choose between b and c.

We need a proper UI to pick between all of a, b and c. We are -not- 
going to decide that two of those options are absolutely enough and that 
the user should be grateful for this UI simplification. That would be 
obviously false as proven by the recurrently complain about both option. 
This is Mercurial, not Gnome-VCS ;-)

>> - `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
>
> That sounds useful. I'm actually surprised that you want to keep the 'hg
> amend' command around -- I had somehow assumed that it was a temporary
> command and that 'hg commit --amend' would be the normal way to amend
> commits. Is the purpose of a dedicated amend command to let people
> uncommit files or are there other uses for it?

Amending (and committing) needs multiple special flag (-U, -D, selecting 
the way to exclude changes) that does noes really belong to hg commit. 
In the final UI will see the inclusion, in core, of new commands 
dedicated to history rewriting. I currently believe "hg amend" will be 
one of them (and Matt, expressed agreement multiple time)
Jordi Gutiérrez Hermoso - July 9, 2014, 1:49 p.m.
On Jun 7, 2014, at 6:28 PM, Angel Ezquerra <angel.ezquerra@gmail.com> wrote:
> 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).

hg rm thefile && hg commit --amend? Is this too difficult?

On Sat, 2014-06-07 at 19:02 -0400, Augie Fackler wrote:
> 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 nd-line users.

It already does for me. The only time I use histedit instead of evolve
now is when I need to reorder commits. For this case, I'm preparing an
`hg reorder` command. 

Other than that, I update to past commits, `hg amend` them, sometimes
I `hg fold` the result, I `hg rebase` stuff around... Evolve really
can provide a complete CLI and thus *scriptable* alternative to
histedit.

- Jordi G. H.
Augie Fackler - July 9, 2014, 1:51 p.m.
On Wed, Jul 9, 2014 at 9:49 AM, Jordi Gutiérrez Hermoso <jordigh@octave.org>
wrote:

> On Jun 7, 2014, at 6:28 PM, Angel Ezquerra <angel.ezquerra@gmail.com>
> wrote:
> > 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).
>
> hg rm thefile && hg commit --amend? Is this too difficult?
>

Doesn't solve the whole problem - I might be trying to split a change or
something, and want to un-commit some changes without discarding the files.


>
> On Sat, 2014-06-07 at 19:02 -0400, Augie Fackler wrote:
> > 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 nd-line users.
>
> It already does for me. The only time I use histedit instead of evolve
> now is when I need to reorder commits. For this case, I'm preparing an
> `hg reorder` command.
>
> Other than that, I update to past commits, `hg amend` them, sometimes
> I `hg fold` the result, I `hg rebase` stuff around... Evolve really
> can provide a complete CLI and thus *scriptable* alternative to
> histedit.
>

histedit will still be a convenient batch tool for mass history editing,
and it'll still stick around IMO. Maybe you'll write your own scripts that
do something similar, but I suspect it's going to remain a pretty big
winner.


>
> - Jordi G. H.
>
>
>
>
>
>

Patch

diff --git a/hgext/mq.py b/hgext/mq.py
--- a/hgext/mq.py
+++ b/hgext/mq.py
@@ -5,7 +5,7 @@ 
 # This software may be used and distributed according to the terms of the
 # GNU General Public License version 2 or any later version.
 
-'''manage a stack of patches
+'''manage a stack of patches (DEPRECATED)
 
 This extension lets you work with a stack of patches in a Mercurial
 repository. It manages two stacks of patches - all known patches, and
diff --git a/tests/test-extension.t b/tests/test-extension.t
--- a/tests/test-extension.t
+++ b/tests/test-extension.t
@@ -569,11 +569,11 @@ 
       patchbomb     command to send changesets as (a series of) patch emails
   
   use "hg help extensions" for information on enabling extensions
-  $ hg qdel
-  hg: unknown command 'qdel'
-  'qdelete' is provided by the following extension:
+  $ hg histedit
+  hg: unknown command 'histedit'
+  'histedit' is provided by the following extension:
   
-      mq            manage a stack of patches
+      histedit      interactive history editing
   
   use "hg help extensions" for information on enabling extensions
   [255]
diff --git a/tests/test-help.t b/tests/test-help.t
--- a/tests/test-help.t
+++ b/tests/test-help.t
@@ -261,7 +261,6 @@ 
        histedit      interactive history editing
        keyword       expand keywords in tracked files
        largefiles    track large binary files
-       mq            manage a stack of patches
        notify        hooks for sending email push notifications
        pager         browse command output with an external pager
        patchbomb     command to send changesets as (a series of) patch emails
diff --git a/tests/test-mq.t b/tests/test-mq.t
--- a/tests/test-mq.t
+++ b/tests/test-mq.t
@@ -15,7 +15,7 @@ 
 help
 
   $ hg help mq
-  mq extension - manage a stack of patches
+  mq extension - manage a stack of patches (DEPRECATED)
   
   This extension lets you work with a stack of patches in a Mercurial
   repository. It manages two stacks of patches - all known patches, and applied