Note the weird format: I have it display “ | ” so I can double-click the hash and copy it. The remaining lines are the ancestry of my current checkout. (Or if you can, you’re looking at this document on bitbucket and the colors are random and crazy.) But the first line is orange, and is the public revision that my current patch stack is based on. Attempt to get error output to appear.Ĥ18150|12723a4fa5eb Bug 1349531 - Remove non-threadsafe static buffersĤ18165|9b790021a6900 - Record the values and thresholds for GC triggersĤ18171|5e12353100f452 - Incrementalize weakmap marking weakmap.incremental My main tool for this is an alias hg ls: % hg lsĤ18116|8b3ea20f546c Bug 1333000 - Display some additional diagnostic information for ConstraintTypeSet corruption, r=jandemĤ18149|44e7e11f4a71 No bug. The biggest thing I missed from mq was an easy way to see my current “patch stack”. That assumes you are currently updated to the “patch stack” that you want to rebase, probably with a bookmark at its head. My usual next step is % hg rebase -d inbound I will usually rebase on top of inbound./mach mercurial-setup should set you up with firefoxtree, which will cause the above pull to advance some local tags that will conveniently give you the head of the various repositories. If you’re pushing to any personal repositories, be sure to mark them non-publishing. I use phases heavily to keep track of what’s “mine”. I also use evolve, though it’s mostly just to make some things nicer. I formerly used mq, and when I’d finally had enough of it, I tried to make my vanilla hg workflow provide as many of the same benefits as possible. I used git first, for quite a while, but it just doesn’t stick in my brain. I don’t know how long I’ll keep them in sync before giving up on one:Īlso, note that the WordPress formatting of this document isn’t very good you’d probably be better off reading this on github, especially since I will be keeping it up to date there and not here on my blog. At the moment, I have it uploaded to two difference places. I’ve published a repository containing some of them. Note that there are good docs already for the “normal” workflow at Ī number of things here use local crap that I’ve piled up over time. I am happy to expand on bits you are curious about. This is going to be more of a summary overview than an in-depth description or tutorial.

But it can be helpful to look at what others do, and see what you might be able to steal. Nor is it the best possible one for me, since I’m a creature of habit and cling to comfortable tools. I thought I’d write up one of those periodic posts describing my workflow.

Waiting for kdiff3 to close