Mercurial Queue
blindwaves
support, I can't seem to find any documentation on it.
Thank you!
Jason Harris
On May 20, 2011, at 10:32 AM, blindwaves wrote:
> Are there any plans to support Mercurial Queue? Or it is already
> support, I can't seem to find any documentation on it.
Right now
-----------------------
As far as Mercurial Queues right now you can use them directly from the command line and MacHg is happy to work with such a repository having the queue. So MacHg is totally compatible with using Mercurial Queues. However, right now there is no direct support in MacHg for *creating* queues or *issuing* queue operations.
Plans
-----------------------
There are plans to support the functionality of Mercurial Queues directly in MacHg.
(Note I use Mercurial Queues myself, and MacHg uses them internally)
The reason is Mercurial queues are another interface layer on top of mercurial. They are there since some of the functionality is not in base Mercurial. But once you have say rebase, collapse, histedit, and strip, you are most of the way there in terms of the functionality that Mercurial Queues provide. The things that you can't yet do is change the details of the commit message, date, or committer through histedit, or split patches.
So in the end here is what I plan for MacHg: I would like to have a "super" history editor for MacHg which is inspired by histedit, but would go much further than histedit currently goes. Eg here is a typical set of "hist-edit rules" as histedit currently produces:
pick 336008a0f681 - Make sure if we load a new tip which is smaller than the pre
pick 7f75888f96df - Add reverse to NSArray and NSMutableArray
pick 864d371d44ed - Use high to low for the entries to add so that the drawing g
pick 2c43975a9d9b - Stop printing these messages upon loading all the time.
pick 3e09977f0d1d - Make tip, parents, and incomplete revision update immediatel
I was going to present this as a tree outline and expand this to something effectively like:
group 336008a0f681 - Make sure if we load a new tip which is smaller than the pre
file 336008a0f681 - Classes/LogEntryModel/RepositoryData.m
group 7f75888f96df - Add reverse to NSArray and NSMutableArray
file 7f75888f96df - Classes/General/Common.h
file 7f75888f96df - Classes/General/Common.m
group 864d371d44ed - Use high to low for the entries to add so that the drawing g
file 864d371d44ed - Classes/LogEntryModel/LogGraph.m
file 864d371d44ed - Classes/LogEntryModel/RepositoryData.m
group 2c43975a9d9b - Stop printing these messages upon loading all the time.
file 2c43975a9d9b - Classes/Application/AppController.m
group 3e09977f0d1d - Make tip, parents, and incomplete revision update immediatel
file 3e09977f0d1d - Classes/LogEntryModel/RepositoryData.m
And each file in this tree could be further expanded down to its list of hunks. Then the user could simply drag and drop groups, files, or hunks to split patches and rearrange things in the order they want. They should also be able to edit the commit messages, date, author, etc at the same time. This then would be the overall model of patch queues except it would be working within normal hg. Ie the patches are always applied and there patch queue is finished.
Thus in the end once I do this I don't think I will have to support patch queues directly in MacHg since this will be powerful enough to do almost anything one wants to do with patch queues. And it does it all within the normal mercurial model...
Doing the tree structure in MacHg will just be an NSOutlineView and that will not be so difficult. I'll have to get the actual diff for everything selected once I go down to the hunk level. Then once I have all the bits its a matter of doing the history edit. I also already have a nice javascript diff visualizer for webkit (which I snatched from git-X.)
The one sticking point is it would be nice to know if there are patch conflicts as you drag and drop and move things around, so for instance a group/file/hunk could turn red as you drag and drop it so that you know a conflict exists by moving it to that position, etc. I will have to write python tools for these parts I think... (difftools is not enough here...)
Alternatives to Mercurial Queue workflows:
-----------------------------------------------------------
One thing which one can do with Mercurial Queues is change code at some past point through something like:
hg qimport --rev 678:tip
hg qpop -a
bbedit .hg/patches/678.diff
<make the changes to the diff that you want...>
hg qpush -a
hg qfinish -a
Better in MacHg would be to:
<MacHg update to revision 677>
<MacHg revert all files to revision 678>
<change the code to the way you want 678 to really be>
<commit the new version of 678>
<rebase 679 and descendants on top of new version.>
<strip 678>
Cheers,
Jas
Victor Hooi
Jason Harris
On Sep 25, 2011, at 8:27 PM, Victor Hooi wrote:
> heya,
>
> Is there any update on this? =).
I have thought about various interfaces for MQ's for a while now. I have something planned and hope to work on it within the coming month / months... :)
> It would be awesome to have Mercurial queues support in MacHg - none of the other OSX Mercurial frontends (Murky, SourceTree etc.) support it from what I can tell, so this would definitely push MacHg ahead of the curve.
:)
Cheers,
Jas