Contributors: how best to handle your local & upstream branches?

[treyharris]

Just a general question here. How do you recommend branching, forking, and setting upstreams so that you can:

• Use your /usr/local/Library/Taps/caskroom/homebrew-cask for your system, even including your own unmerged casks
• Hack on homebrew-cask code (casks and in the commands core) and test it live
• Run brew update without being prompted for merge commits every time?

(First, let me assure you I do use feature branches, so I'm not being completely stupid here. But at some points, I sometimes want to actually apply those features to my system even if they aren't merged into this origin (yet).)

At first, I used the hub CLI defaults for cloning and creating tracking branches in one fell swoop, which gave me a master tracking my fork at remote treyharris, and an origin remote (pointing at caskroom/homebrew-cask/master, of course) with no tracking branches. That let me merge local stuff into my master and fetch and merge manually from the origin/master. But then the first time I ran brew update, and every time thereafter, I got prompted for a merge commit when it got to the caskroom tap. Ugh.

So I backed up and I tried brew update --rebase, and that looked good the first time, but it ended up worse, since after the second time it gave me rewritten commits with hashes on my local commits that didn't match already-pushed commits at treyharris/master, so I had to reset my branch on GitHub (good thing nobody was forking it!) and start over.

Should I have master pristinely track origin/master, use some other branch to track treyharris which I will ordinarily keep checked out (and hence the one in use by the running system), and try to remember to checkout master each time before I run brew update? (I could alias (cd /usr/local/Library/Taps/caskroom/homebrew-cask && git checkout master && brew update && git checkout -) fairly easily if that's the best solution.)

Or is there a cleverer way? I was looking at the various branch\..* and remote\..* config options thinking, "there's gotta be a neat way to handle this", but I bet y'all have this down pat. Any suggestions?

I gotta say, homebrew's separating out the formulae into a separate repo is a big help for my not having the same issue there, so looking forward to Casks getting separated as well.

p.s. While I'm asking: how do you play around with changes you make to the code? In non-desktop Unix admin, which is where my professional background lies, you'd use a dev sandbox machine or run a virtual for that kind of thing. How about you guys? Do you run a separate throwaway Mac for that purpose, do you have some OS X virtualization method, or do you just trust the tests and not worry about running live experimental commands on a live machine?

[rolandwalker]

Different developers have done this differently. I use the setup described in HACKING.md:

• there is a typical working install of Homebrew and Homebrew-cask in /usr/local
• there is a separate dev clone of homebrew-cask in a personal directory
• in that clone, repo caskroom/homebrew-cask is called upstream
• in that clone, repo <github-user>/homebrew-cask is called origin
• run ./developer/bin/develop_brew_cask from inside the clone to juggle symlinks so that brew cask commads run off of the personal clone
• feature branches are pushed my personal repo aka origin, and a PR is generated from that (GH will understand this and prompt me from the web interface)

Drawbacks:

• You can't run brew update while those develop_brew_cask symlinks are in place. You have to remember to run

  ./developer/bin/production_brew_cask && brew update && ./developer/bin/develop_brew_cask

• hub doesn't like the repo names I'm accustomed to. It wants to send a PR to origin. So you might want to configure the repo names as origin+treyharris rather than upstream+origin. The symlink script above is agnostic about the repo names. (I never figured out how to configure hub.)

As for VMs, I definitely test pkg-type Cask installs in a VMware VM. Other Casks are safer because they don't have uninstall — though that is about to change. VirtualBox is more popular here than VMware.

See also: forcing fully-qualified command without twiddling symlinks.

[rolandwalker]

Updates to HACKING.md are welcome. I am certain that it does not actually contain everything you need to know to get started.

It somewhat irks me that the documented brew cask create git workflow is completely different from HACKING.md. But maybe different workflows are appropriate for different use cases.

[treyharris]

@rolandwalker Thanks, great info!

Stupid question: how do you best run OS X in a VM? Last I heard, Apple made it very hard to do so.

[alebcay]

I typically use brew cask create, and make my new cask accordingly (this is residing in /usr/local/Library/Taps/caskroom/homebrew-cask/Casks), without running the ./developer/bin/develop_brew_cask.Then, I usually run brew cask audit <CaskName> and also I cycle through brew cask install <CaskName> and brew cask uninstall <CaskName> once to make sure it all works. Such testing sometimes breaks my computer (e.g. when I tested paragon-ntfs and parallels, but I'd rather that break my system at a time that I am ready and prepared to fix it than when it is installed on someone else's production machine that is not prepared for such an event).

Finally, when everything's working, I update my development repository (located on another volume) to the latest upstream (and push to send these to my GitHub fork), and make a new branch for the commit.

git pull upstream master && git push && git branch <CaskName> && git checkout <CaskName>

Finally, all that's left is to move over the Cask file from my production system into the development repo (I say move and not copy so that I don't accidentally leave it there and fail an update when my PR gets merged). With a push off to my fork branch, it's then up in GitHub.

mv /usr/local/Library/Taps/caskroom/homebrew-cask/Casks/<CaskName>.rb Casks/<CaskName>.rb
git push origin <CaskName> # you must specify branch to push to (usually) because default remote has not been set

From there, I just go to GitHub and submit the PR.

---

Stupid question: how do you best run OS X in a VM? Last I heard, Apple made it very hard to do so.

Indeed, they did. I would suggest multibooting instead (the second OS can be periodically wiped/re-imaged/etc).

[rolandwalker]

@treyharris as far as I know, VMs are easy for Mavericks and later, if hosted in OS X, on Mac hardware. For the latest VMware it is a dead simple "create a VM" which launches a wizard. For VirtualBox, someone else would have to answer. If you are not on a Mac/OS X stack, I think Apple actively tries to stop you.

[vitorgalvao]

Using VMWare, it is indeed dead simple, as is (from what I’ve read online) the case with Parallels. They’re both commercial applications, and while searching around (less than one year ago), Parallels certainly came of as being superior (or having more vocal fans, I suppose) while at the same time being criticised for every year launching paid upgrades with very few and negligible new features, but that is compatible with the new OS version. VMWare isn’t different, though (although I haven’t read criticism on this point, despite them doing the same); I don’t know why they don’t just use a subscription model, but I’d sure like to. It is cheaper than Parallels, fits my needs well, and I’ve used them before many years ago, so that’s what I use now, although I’m not sure I’ll stick with it.

Apple allows you to legally run OS X on VMs (it’s on the OS’s license) as long as it’s on Mac hardware, as @rolandwalker mentioned. If you comply with that, they likely don’t give a crap how you do it, and these commercial companies sure can get it working by the time the OS is released. If you want to be a bit cynical, it sure seems like they purposefully build the software in a way it will stop working on new versions¹, just to force you to pay again. This are suppositions, naturally, but be aware that if you continue to upgrade your OS, you’ll also need to pay for the software over and over, on a predictable time schedule, with disappointing new features².

Regarding VirtualBox, you’ll likely need to try and see. Don’t get your hopes up, though. I’ve used it many years and it seems to be inferior in possibly every way, from interface to usability and actual capabilities. It also has (had?) some issues running on newer Macs, that have been going on for quite some time. I could install Mavericks on Mavericks in a 2004 MacBook Pro, but could not do it on a Retina MacBook Pro from 2013. It is a known issue, and you’ll find references to it online (that’s how I knew it wouldn’t work). It is free, though³.

---

¹ Or at the very least if it only needs a small tweak, they’ll ignore that and launch a new version anyway.

² “Bitter”? What do you mean?

³ Or, let’s say you don’t pay with money, but possibly with headaches.

[mAAdhaTTah]

I personally run a Hackintosh, and I've used Niresh to install Mavericks on VirtualBox (guide linked), although that's not the method I use for my Hack itself. I did use this method to test Kitchenplan, Chef-based provisioning script.

That said, I don't hack around with Cask core myself, so I would imagine it would be tedious to work with VirtualBox's terrible window manager for an extended period of time.