A while ago I blogged about my git-bz tool for Git and Bugzilla integration. If you recall, the original idea was:
git bz attach http://bugzilla.example.com/show_bug.cgi?id=43215 HEAD
But that left a gap – once you were happy with the patch, how did you close the bug? You had to go back to your web brower, and twiddle a bunch of form controls. So, I’ve now added:
git bz push
Which looks at the URL that ‘git bz attach’ added to your commit message, finds the bug from there, and pops up a prefilled editor. It looks something like:
# Bug 43215 - Split HTTP communication out of Bug class - UNCONFIRMED # http://bugzilla.example.com/show_bug.cgi?id=43215 # Enter comment on following lines; delete everything to abort Attachment 892 pushed as f319ea4 - Split HTTP communication out of Bug class # Comment to keep bug open # possible resolutions: [F]IXED, [I]NVALID, [WON]TFIX, [WOR]KSFORME Resolution: FIXED # Lines below change patch status, unless commented out # possible statuses: [n]one, [rev]iewed, [rej]ected, [c]ommitted, [o]bsolete committed @892 - Split HTTP communication out of Bug class - none
You can just accept it, or you can make changes and add additional comment text. Once you exit the editor, the bug is closed and the attachments are marked committed.
Even more recently (just today) I implemented a feature request from Benjamin Otte for:
git bz push --fix 43215
This combines ‘git bz attach’ and ‘git bz push’ into one. So, to review, what it does is:
- Rewrites the commit to include the bug URL
- Attaches the commit to the bug, and marks it ‘committed’
- Pushes the commit
- Adds a comment to the bug and mark it resolved
The only thing it doesn’t do is mail your boss and ask for a raise.
Some of the other recent activity for git-bz:
- Fixed to work with new GNOME bugzilla
- ‘git bz edit’ – like ‘git bz push’, but not tied to a push. (So, you can just use it instead of the web when convenient.)
- Customizable “URL addition” – you can have “Bug nnnn – ” on the subject line instead of an URL appended to the commit body.
- “URL addition” defaults to on, so you don’t have to remember to pass -u/–add-url
- No need to specify the bug # when re-attaching an updated version of a commit
- XML-RPC used for bug filing when available (improves error handling a bit)
- Chromium cookie-reading support (from Colin)
- Docs split out into a man page
As always, installation is trivial – just grab the script and put it somewhere in your path. (Or get the git repo URL from cgit, clone it, and symlink.)
fishsoup 
18 Comments
any plans to post this script for inclusion in git upstream?
git-bz is a large Python script. Converting it into a large Perl script and maintaining it that way doesn’t have much appeal to me as fun spare-time hacking. git upstream does have a number of Python scripts in contrib/ but I think it’s healthier to have it as a separate project than off in a contrib/ directory. So, no plans to try to get it upstream.
Two typos:
showbug?id=XXXX
ˆˆˆ
id= is missing in the first reference
git push –fix XXX should probably be git bz push –fix XXX right?
Sharp eyes. Fixed.
Would be nice if the bugzilla part was stripped out in favor of something like pybugz.
owen++
There’s two nitpicks left:
1) git bz file should query the components for me if I didn’t set one. I always fail to get capitalization correct, then edit the bug text before being greeted with an error. (Oh, it was “GtkFileChooser”, not “filechooser”)
2) A large database matching git repository names to bugzillas, so that it knows that a repo named “cairo” goes to bugs.freedesktop.org and the product is “cairo” while gtk+ goes to bugzilla.gnome.org’s “gtk+” product.
This should be added to the hooks on the git server so that bugs automatically get closed when you push.
The only part of this you could really meaningfully do on the server is the last step of closing the bug. And even for that I like a client approach better since there is the chance of interaction.
What if you put “Fixes gnomebug:534321″ in your comment and you typo’ed the bug #”? A server hooks script would happily close some random bug and you might never notice. This way, you see that it’s proposing to close the wrong bug before it does anything.
I think you should have a look at SD: http://syncwith.us/sd/
Thanks, Owen. I love git-bz, and this is a great update.
You should have a look at WebKit’s bugzilla-tool. That can be found in the WebKitTools/Scripts subfolder.
Cheers,
Kenneth
Yep, conceptually pretty similar. Glancing through the toplevel options I don’t see anything that I really wish git-bz does and it doesn’t. Maybe someone who had experience with both would have there favorite thing they could do with bugzilla-tool.
git-bz is strongly tied to git in command line style and concepts. bugzilla-tool is implemented with SVN, but seems to try and and be more “generic” in flavor.
In terms of Bugzilla integration implementation, there’s a pretty big difference in that bugzilla-tool uses BeautifulSoup and mechanize so “drives the web interface” while git-bz uses a combination of XML-RPC where possible and knowledge of the POST interfaces that the web interface uses. git-bz has no external non-standard deps while bugzilla-tool uses the above modules and lots of WebKit specific glue.
One thing supported by bugzilla-tool is editing flags of attachments (to ask for review for instance). It’d be nice to have git-bz somehow support that too 😉
I think flag editing would be a nice addition; I’m not sure I’ll get around to working on it myself, because I’m almost always using git-bz in the context of GNOME bugzilla, where we don’t use attachment flags (we use attachment status for somewhat similar purposes.) But contributions in that area would definitely be accepted. I’d think that the most important thing to support would be setting flags when filing a patch with ‘git bz attach’ or ‘git bz file’ – changing flags later with ‘git bz edit’ seems peripheral; that I see more as something that should be supported by Splinter when reviewing a patch. Probably the most challenging part about flags is figuring out how to figure out what flags are available and change them; I’m pretty sure that there is no representation of flags in the XML-RPC interfaces currently, so either those interfaces would have to be extended upstream, or some nasty HTML scraping would be involved.
I sent you some patches for that, did you get them?
Found them in my spam folded and retrieved them. Thanks for the ping. There’s now a git-bz component on bugzilla.gnome.org where patches can be attached. (With git-bz even!)
@Gilles,@kaeso – there are certainly many other bug/defect tracking systems out there. It wouldn’t be impossible to generalize git-bz to work with a different system, but it would be a job – you’d have to refactor the whole code to have a “bug tracker” abstraction. And if not done carefully the UI would suffer because all the docs and command line options would be “abstracted” too and no longer match up closely with one system.
There are things I don’t about Bugzilla – the old-fashioned form-posting web interface, the “bug ghettos” formed by each Bugzilla installation. But it’s very mature and lots of projects use it for looots of bugs. I think a tool that works really well with Bugzilla is valuable as such.
I eagerly await your git boss-raise integration. For now I will just try out this simple bugzilla code you produced. 🙂
One Trackback/Pingback
[…] fishsoup Owen Taylor on Coding, Food, etc. « git bz push […]