When you want to commit changes with Monticello, you have essentially two ways:
- Monticello Browser (or Nautilus)
The problem with Monticello is that it is really an all-or-nothing solution… you just enter the commit description and that’s it. This is fine most of the time, but not always — maybe you want to commit across several packages, or maybe you want to commit just a single method. Not to mention that you don’t actually see what you are committing, unless you open a separate changes diff.
To address this problem, there’s a
Komitter tool (World > Tools > Komitter). Unfortunately, this tool has a different problem — it shows you the changes in the entire system, which considering I have a lot of custom system overrides is a lot.
Of course, I can manually not include everything I don’t want, but that’s a lot of work since I would have to do it every time.
So, let’s find a middle ground. Looking at the
Komitter class, I found a suspicious method
Komitter class>>openAndCommitToMonticelloWorkingCopiesFilteredBy: aFilterBlock
This method opens the Komitter just on working copies (=the uncommitted packages) matching
aFilterBlock, which means I can do something like this
That’s so much better! But who would want to type something like that every time?
Nautilus can be extended in many ways, one of which is extending the context menus. I want to add an entry just above the “Changes with…” that would open
Komitter on the selected package(s).
All we have to do is to define somewhere a class-side method containing the
For inspiration, we can take a look at the class side of
NautilusMonticello where we can find the definitions of the currently visible menu.
So, to add new entry, let’s create a new method on the class side of
*MyKomitter-menu protocol (it doesn’t matter where it is, but I like to keep extensions close to what they operate on).
target in the above script is
NautilusUI instance (you can always throw in
self halt to explore). The
order has been taken from
NautilusMonticello, so it’s just where I wanted it to be.
And we are done!
Finally, since I wouldn’t want to add it manually every time, I’ve made it into a startup script — simply compile the method into the class on first startup (don’t forget to save the file wherever your Pharo’s startup scripts are stored). (There’s a small bugfix included for Pharo 5.)