insomnia bytes

If you’ve been hanging around the XMMS2 hype-sphere lately, you’ve certainly heard “wait for rv-split to be merged” almost as often as “it should be a service client”. Well, wait no more, for rv-split has made it into the -devel tree!

It means that all C clients are broken now, and possibly clients in other languages too. Yes, yours too. It needs fixing, and I’m going to explain how.

But, you ask, what is rv-split in the first place?

The result/value-split, AKA “rv-split” or sometimes just “rv”, is a change in the XMMS2 clientlib. Up until now, values returned by the server were kept inside the

structure that you got back from the call. The data was to be fetched directly from the result.

In sync mode, it went something like this:

The goal of rv-split was to isolate values outside of the result structure (for reasons that will become more obvious when we talk about the async calls). To do that, we introduced a new structure called

(for “xmms value”), that can contain any type of value. Accessor functions are used to extract each type from it, in a similar way to how it was done with result structures.

Let’s show the sync example again:

All we have to do is extract the

from the

. No raw data is stored in the result structure anymore.

read the rest of this entry »

Sometimes you’ve played around in the history of a branch, edited some stuff in older commits, perhaps reordered them. You’ve reset’d back a few commits, and now you want to get to the final state you were at initially (or whatever state you want to get to).

Say you’ve kept a branch called ‘

‘ with the working end state you wanted to get back to before you started messing around with the history. You don’t want to

(merging two alternative histories of the same development wouldn’t make any sense), you don’t want to

(it’s about building a new history, not forwarding it on top of the old one). You just want a new commit to bring you to ‘

‘.

And you want to get there now!

The intuitive way to do this is the following:

$ git diff ..the-end-state > finish.patch
$ patch -p1 < finish.patch
$ git commit -a -s

But why three steps when you can do with just two, using

to import the tree from

branch into your index (

to check for unmerged entries) and populate your work tree (

):

$ git read-tree -m -u the-end-state
$ git commit -a -s

Thanks Junio for the tip on gitml!

Just opened this new blog at bytes.inso.cc to host ramblings and thoughts and tips about computer-related stuff. The idea is to stop scaring my grandfather, who does read my regular blog, and start posting more regularly about XMMS2, Git, mindmaps, the power of syndication feeds, crappy/genius UIs, Information Architecture, Human-Information Interaction and other such trendy buzzwords.

And perhaps it will encourage others to blog more regularly on the XMMS2 Planet!

So, stay tuned…