The joy of open source software
A few years ago, after B*tm*v*r went insane and rudely pulled the plug on all of their open source users, I switched over to Linus Torvald’s git because it was the only the version control system that worked (close to) the same, plus was written in C instead of some thrice-damned vanity language that wouldn’t work on some of the older machines I use for development. It’s (obviously) a Linux program, which meant that it didn’t work out of the box on anything other than modern Linices, but with a couple of days work I was able to wrap my configure.sh around it and get it to compile on SLS Linux, FreeBSD 4.5, and MacOS 10.0.4 without fuss or bother.
And then I happily used it for quite a while, building up a circle of repositories on my server farm, doing development on any of the machines and just pushing the changes around to the other machines to keep everything in sync.
You can guess where this is leading, can’t you?
When I finally moved out of my flaky co-lo, I replaced gehenna with a virtual server running a more recent version of FreeBSD, and, rather than try to install git 1.5.2.2
(which doesn’t build because gcc is convinced that the system header files are trying
to redefine sockaddr_t (but it’s not going to fucking tell me where this alleged redefinition is happening. Oh, no, that would make it easier to program in C and keep me from coding in P*th*n or whatever other t-dvl the FSF is shilling for this week)) I just grabbed git 1.7.0.6 off the ports heap and installed it instead.
At first, it was fine; I could push out changes from pell & downbelow and run my automated unit tests without fuss, muss, or bother, so everything seemed okay.
But then something flaked out inside postoffice and I ended up doing a little bit of coding on the new virtual gehenna to figure out why. A few days later, I tweaked something in postoffice on downbelow, turned around to push the changes out to the other servers, aaaand…
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error:
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error:
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
So I did a brief check online, and discovered that apparently the old behavior of push was a little bit too egalitarian for the new improved git core team, and that being able to push into a useful repository is now the moral equivalent of dumping diphtheria into the city water supply.
To hell with that nonsense:
--- builtin-receive-pack.c~orig 2010-05-10 12:23:21.000000000 -0700
+++ builtin-receive-pack.c 2010-05-10 12:22:00.000000000 -0700
@@ -351,10 +351,13 @@
break;
case DENY_REFUSE:
case DENY_UNCONFIGURED:
+#if 0
rp_error("refusing to update checked out branch: %s", name);
if (deny_current_branch == DENY_UNCONFIGURED)
refuse_unconfigured_deny();
return "branch is currently checked out";
+#endif
+ break;
}
}
Dear git core team;
Thank you for offering to bolt training wheels onto my bicycle, but I already know how to ride the effing thing and I don’t need your nasty safety equipment in the least. I don’t care if the branch is “checked out” (didn’t that go out with CVS, or is CVS now the gold standard for those of us who can’t afford Clearcase?) when I attempt to synchronise it with the rest of the farm. If I can’t automerge it, I’ll just do it by hand the way I’ve been doing for the past three years.
Love,
BPFH