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