git your blog

So I deleted my whole website by accident.

Yep, it wasn't very fun. Luckily, Linode's Backup Service saved the day. Though they backup the whole machine, it was easy to restore to the linode, change the configuration to use the required partition as a block device, reboot, and then manually mount the block device. At that point, restoration was a cp away.

The reason why this all happened is because I was working on the final piece to my ideal blogging workflow: putting everything under version control.

The problem came when I tried to initialize my current web folder. I mean, it worked, and I could clone the repo on my computer, but I couldn't push. Worse yet, I got something scary back:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

So in the process of struggling with this back and forth between local and remote, I killed my files. Don't you usually panic when you get some long error message that doesn't make a darn bit of sense?

Yeah, well, I guess I kind of got the idea, but it wasn't entirely clear. The key point is that we're trying to push to a non-bare folder— i.e. one that includes all the tracked files— and it's on a main branch.

Why is this bad? Well, what if you had uncommited changes on the remote repo and you pushed changes from the local repo? Data loss. So Git now won't let you do it unless you specifically allow it in your remote config in the receive.denyCurrentBranch variable.

So let's move to the solution: don't do this. You should either push to a different branch and then manually merge on remote, but merges aren't always guaranteed. Why not do something entirely different? Something more proper.

First, start with the remote:

# important: make a new folder!
git init --bare ~/path/to/some/new/folder

Then local:

git clone user@server:path/to/the/aforementioned/folder
cd folder
# make some changes
git add -A
git commit -am "initial commit or whatever you want to say"
git push

If you check out what's in that folder on remote you'll find it has no tracked files. Basically, a bare repo is basically just an index. It's a place to pull and push to. You're not goinng to go there and start changing files and getting git all confused.

Now here's the magic part: in the hooks subfolder of your folder, create a new executable file called post-receive containing the following:

#!/usr/bin/env sh
export GIT_WORK_TREE=/path/to/your/final/live/folder
git checkout -f master
# add any other commands that need to happen to rebuild your site, e.g.:
# blogofile build

Assuming you've already committed some changes, go ahead and run it and check your website.

Pretty cool, huh? Well, it gets even better. Next push you do will automatically update your website for you. So now for me, an update to the website is just a local push away. No need to even login to the server anymore.

There are other solutions to this problem but this one seems to be the most consistent and easy.

Read and Post Comments

happy Ubuntu Community Appreciation Day, phillw!

I swear, I find out about some new event Ubuntu does every day. How is it that I've been around Ubuntu for as long as I have and I've only now heard about this?

Well, in any case, today is Ubuntu Community Appreciation Day, where we give thanks to the humans (remember, ubuntu means humanity!) that have so graciously donated their time to make Ubuntu a reality.

I have a lot of people to thank in the community. We have some really exceptional people about. I really feel like I could make the world's longest blog post just trying to list them all. Several folks already have!

Instead, I'll point out a major player in the community who is pretty unseen these days.

Phill Westside was a major contributor to Lubuntu. He was there when I first came to #lubuntu so many moons ago. His friendly, inviting demeanour was one of the things that kept me sticking around after my support request was met. Phill took it upon himself to encourage me just as he had with others and slowly I came to contribute more and more.

Sadly, some people in high rankings in the community failed to see Phill's value for whatever reason. I'm not sure I totally understand but I think the barrage of opinions that came from Jono Bacon's call for reform in Ubuntu governance may offer some hint. Phill's no longer an Ubuntu member and is rarely seen in the typical places in the community.

Yet he still helps out on #lubuntu, still helps with Lubuntu ISO testing, still reposts Lubuntu news on Facebook, still contributes to the Lubuntu mailing lists, still tries to help herd the cats as it were, though he's handed off titles to others (that's how I'm the Release Manager and Head of QA!). tl;dr, Phill is still a major contributor to Ubuntu.

Did I mention he's a great guy to hang out with, too? I've never met him face to face, but I'm sure if I did, I'd give him one heck of a big ole hug.

Thanks, Phill!

Read and Post Comments

fullscreen slides in Hangouts workaround

More to come on the Ubuntu Online Summit soon but in the interim, I wanted to bring up something I learned a little too late.

Google Hangouts is handy little tool. Outside of providing an alternative to the likes of Skype, it also features some useful apps for using with a virtual tech conference like UOS really is. One of them is called Hangout Toolbox and has a feature called "Lower Third" that will allow you a pretty logo-ized tag line.

But the thing really useful to something like UOS is the default Screenshare app. Clicking on it, you get the option of either sharing the entire screen or one of your windows. So logically, you open the window with your presentation and start the full screen slide show, right?

Yeah, not exactly. I did that and I was going along talking away for my first presentation and no one could see anything beyond the first slide. I was manually advancing and it looked good on my side, but to everyone else, it was just frozen on the title. Since I was in full screen mode and no one had yet joined the Hangout, I had no idea what was going on though people were trying to get my attention on IRC.

I discovered a solution rather quickly: a windowized presentation. That is what I ended up doing, but things can look kind of tiny. Still, there are hoardes of posts out there on people doing similar things in PowerPoint and Keynote.

This is not the right way, though. We want full screen. So how do we do that?

It's simple, really. You share the full screen— not a window— then navigate to your presentation and start the slide show.

I guess that Hangouts thinks that the full screen window is not the same as the app window itself. Which is strange because, according to xprop -root | grep ^_NET_CLIENT_LIST, it's not a different window.

Unfortunately, unlike a lot of the other tools that the community uses, Google Hangouts is not open source. We can't just file a bug report and get to work on it (though you can file a bug report). This is really contrary to the spirit of Ubuntu. In fact, there's already a bug report for this very problem, the proprietary nature of Hangouts (not the first such issue, either).

It seems that especially for this public gathering of Ubuntu contributors and users, that this would be the most important place to put our best open source foot forward. That being said, I encourage you to confirm the bug and participate in helping to find a cure (rather than a mere treatment) to the malady of copyright.

Read and Post Comments

« Previous Page