Even easier backouts from the trees
Some time ago I posted a simple shell script to automate trivial backouts, using the method suggested by Ehsan Akhgari and improved by Daniel Holbert.
I used that script multiple times, as well as others, and I got lot of feedback on issues:
- It was made of 2 separate functions
- The functions had ugly names, to remember the correct order of arguments
- Passing bogus changesets could generate empty backout patches
- the commit message was missing the bug numbers
All of these issues are solvable, and since I'm still a noob at shell scripting, I decided to try again and fix them (as I previously stated, this could be better made as an hg extension).
The new version is a bit larger, so I posted it into my wiki user page for now:
- it is a single function, called backout. You can pass to it a list of changesets or ranges, as:
- backout dddddddddddd:bbbbbbbbbbbb aaaaaaaaaaaa (will backout aaaaaaaaaaaa and everything between bbbbbbbbbbbb and dddddddddddd extremes included)
- The function figures by itself the correct order of the changesets
- if, by chance, an empty backout is generated, it will bail out and notify you
- the commit message includes the list of all the changesets and, if a bug number is found, it will be added near its changeset
Finally, something that did not change from previous version:
- This doesn't merge. Instead it generates a mercurial queue patch, called backout.diff. You can check the contents of the patch before pushing it. Then you can just hg qfin -a && hg push. You can even just qdelete it, if you are not satisfied.
- it assumes you don't have uncommitted changes in the tree. If you have any, they'll be lost. So be sure you have qref the qtop patch, before proceeding.
- If it can't solve a conflict (usually with a later conflicting patch) it will bail out. Complicate backouts should still be done manually. Though, in the last 6 months, I only saw a couple of those.
- It will try to open the editor you set in your hg config, to change the backout message.
- To use the script, just add it to your .profile. Even on Windows, if you use MozillaBuild, you can add a .profile in C:/Users/your_username (or whatever your profile folder is) and restart the MozillaBuild shell.
Finally, I want to thank Ed Morley, for helping me with testing and feedback. He uses the script almost everyday on Inbound and Central, that's a good testing field!
Now, go grab it if you wish, feedback and suggestions are welcome!
quattro commenti
That does seem handy, but you’re right, it feels like it ought to be a mercurial extension. So I took a stab at one. It’s called ‘qbackout’, and for now I put it into my grab bag extension at https://sfink@bitbucket.org/sfink/mqext
It could totally be split out into a standalone extension (and maintained by somebody else!). The only thing it shares with the rest of mqext is the bug matching regexp.
Differences: – any uncommitted changes will fail – it leaves your existing mq patches as-is, and pushes the backout(s) on top – by default, it uses a backout changeset per change being backed out (but it has a -s flag to fold them into a single change, as with yours) – it uses hg syntax for revisions, so the equivalent of your example would be “dddddddddddd:bbbbbbbbbbbb+aaaaaaaaaaaa” – it doesn’t open the editor by default. -e for that. (it just seemed more in line with existing commands.) – I think you may need to add the ‘-U’ option to the [defaults] section of your .hgrc so it will fill in the Author field properly
I moved it over to https://bitbucket.org/sfink/qbackout/ and fixed the (major, fundamental) bug that broke jlebar’s backouts today — I was using the internal logic behind hg’s backout command, except that I was using the part shared with the ‘revert’ command, and so it could only handle reverting tipmost revisions. As it turns out, there’s no slick internal command for doing this, so I switched over to doing the equivalent of hg export | patch -R (though I’m still using the internal mercurial machinery for it.)
Feel free to fork it and maintain the primary download location for it!
Though in the process, I realized that this command might be mostly overlapping with hg transplant. I think you might be able to replace this command with an alias based on hg transplant —filter. (I hadn’t really used transplant before; it mostly came to mind because I read the hg 2.0 release notes that said there’s a new ‘graft’ that mostly takes over from transplant.)
As Marco said, I use this most days and it really is a timesaver – thanks!