Independently discovered a few days ago, it seems.
git-brunch: the power of an idea whose time has come.
A DVCS survey went out recently to GNOME SVN committers, and the results came out a couple days ago. There is much nuance to pull out of the data, but I think that it's fair to say that the respondents prefer git.
The survey was not posited as a referendum on whether or not GNOME should switch to a particular DVCS, but it certainly sheds light on the question.
Unfortunately, the resulting thread on desktop-devel has been quite nasty -- there are a lot of very legitimate concerns coming out, but even Behdad (whom I respect) at one point took an entirely reasonable post as a personal attack.
This is looney.
We're not here to win some kind of victory over each other, to turn other people into losers -- we're here to build something that's bigger than we are. We should remember this when we communicate. We should read at a deeper level to find out what's really on people's minds, to acknowledge those concerns, and work from there to build things, not to tear people down.
Enough of that. One of the options on the table was a really neat hack from John Carr, in which repositories could be accessed via git or bzr.
So, everyone should see this as being a pretty sweet hack, I think. But it has many downsides, and not all of them were mentioned in the ensuing discussion:
The canonical repository format would be bzr, not git. Preferences for git often are based on its semantic model and repository format, so this would be going against developer preference.
Thus, bzr web tools would probably be used instead of git web tools. Personally I prefer cgit and gitweb to loggerhead, though loggerhead has improved quite a bit recently.
Bzr revisions would be the primary way to refer to code. You couldn't say "check revision 034fea225", you'd have to say "check revision 1". So in practice, bzr and git would not be equal, neither from the admin side, nor the developer side.
I was one of the 14 respondents of the survey that actually *use* bzr and git. I mantain many projects in bzr, but am in the slow process of switching to git. Initially I was attracted by the bzr idea that you can usefully refer to revisions by simple numbers, but time has convinced me otherwise.
I want my family jewels in a safe place. When I refer to a revision, I mean that revision and not another tree and history that happens to be the 35th in a series of patches.
Joe Shaw has a few more.
There is of course the important caveat regarding renaming, which many git proponents fail to acknowledge. But my instincts are that if git works for the kernel, its renaming heuristic failure rate should be equivalent to the rate of me starting a new file, but saying it was a copy, or my starting a copy and saying it came ex nihilo. But that's just my feeling -- I have no data on that.
apologies from a git supporter
As one who now prefers git, I would like to apologize to users of other version control systems, especially bzr: for the VCS BOF at GUADEC that wasn't, for the tone of git proponents, for the FUD, and for a general lack of respect. And for ongoing git UI crappiness, though it has improved quite a bit.
But I think that git's the best thing going, and so do most of the other survey respondents. We should figure out a pragmatic way forward that takes all perspectives into account, and I think that Behdad's proposal is a good start.
So I'm a big fan of these new distributed version control systems. For most of my personal projects I use bzr, which works fine and doesn't tax the brain too much. At work (awesome web site) we use git, which I have grown quite fond of.
These systems, while distinct, do share obvious similarities. They're all distributed and more or less fast, they all eschew changelogs, they all do tree-wide atomic commits. So the obvious question I know that you have on your mind is, "Isn't there a rocking emacs mode that can support all of these things?"
OK if not, you should probably stop reading. Otherwise, DVC is your answer. It's super. Here's how to get it:
cd ~/src bzr get http://bzr.xsteve.at/dvc/ cd dvc autoreconf -vif mkdir ++build/ cd ++build/ ../configure make
Then add this to your .emacs:
(add-to-list 'load-path "~/src/dvc/++build/lisp") (require 'dvc-autoloads)
Then restart emacs (or C-x C-e after each of the closing parentheses), and open some file that's in git (or bzr, or monotone, ...). Edit something, save, and type M-x dvc-diff. You get a list of files that changed, followed by diffs. You can use j to jump back and forth between the file list and the diffs, n and p to navigate between diffs, or C-c C-c to go to the file in question.
Most excellently, pressing t will open a new buffer for the commit log, with a nicely-formatted log entry (similar to C-x 4 a), which you can edit, save, kill, whatever -- the next time you press t in the dvc-diff buffer, you'll have that same log message to edit. Until the point at which you want to commit, at which time you might want to press g in the dvc-diff buffer to refresh the diff, then C-c C-c in the log buffer to actually commit the change.
The nice thing is that all of this works regardless of the VC system that you're using. Each system also has some extra methods you might be interested in (e.g. xgit-apply-mbox), but more or less you can treat them the same.
As an aside, I think people that like git do so out of a kind of software Stockholm syndrome: you have to learn so much about esoterics like refs, the object database, the index, etc. that you end up feeling empathy for git's idiosyncracies. Because objectively, git's working tree index should not be a concept that occupies space in my mind.
A couple of weeks ago I was hacking on a GStreamer element from gst-plugins-bad and realized that I needed a way to record my changes in pieces, but not commit to the repository. GStreamer uses CVS, which does not support this workflow.
Bazaar to the rescue, then. I created a new local repository, in the plugin directory. It's as simple as typing bzr init, adding the files you want to track, and then committing as you make changes. I ended up committing a dozen patches or so.
Of course, when I was finished I wanted to push the changes upstream. Thus the point of this writing product, a script to turn a bzr repository into a series of patch files on disk:
#!/bin/bash set -e patchbase=$(basename `pwd`) outputdir=$1 if test -z "$outputdir"; then outputdir=.; fi revno=`bzr version-info | grep revno | cut -d: -f2` echo "exporting $(($revno)) patches..." for ((i=0; $i<$revno; i=$i+1)); do file="$patchbase.diff.$(($i+1))" echo "exporting $i..$(($i+1)) to $file" # dunno why bzr always returns $? != 0 bzr log -r$(($i+1))..$(($i+1)) > $file || true bzr diff -r$i..$(($i+1)) >> $file || true done
I then reverted my tree, applying and committing the patches one-by-one with e.g. patch -u -p0 < foo.diff.4. I'm sure there's some kind of more integrated plugin to do this, but a 10-minute shell script was easiest to hack out.
As an aside, bzr uncommit is quite useful for producing a readable history -- I often go back and modify the committed patches so that they are more understandable on their own.
My last entry on Flumotion internals began with a rhetorical question, something like "why aren't more people hacking Flumotion?" Unexpectedly, I got some real responses in the comments, all quite good. The general theme is that "developers are users first". If your project doesn't present itself well and offer a good initial experience, you're shutting off potential contributors as well as users. So say HiHo, Kalle, and Michael, more eloquently than I.
But that's not the best part. Launchpad offers a web-based repository browser, including changesets, and offers the ability to subscribe to any branch it knows about. You get emails on distributed commits. This is a beautiful thing! Anyone who has worked with distributed VCS's has probably had the feeling that they are seeing development through a keyhole, that there's a whole world out there that's not easily visible or comprehensible. Launchpad offers the possibility of tying together the various development branches out there in the wild in one place, effectively removing the last advantage of centralized version control. Nice job, Launchpad hackers!
I have no current plans to rely on Launchpad for this service, as it is not free software. However, the genius of distributed VC is that I don't have to rely on it; I can continue working like I normally do, commiting my code to archives hosted elsewhere, but if Launchpad is available (probable), I can use it to keep track of things. It helps me work better. I don't need anyone's permission for it to help me work better, either; I just tell it about the bazaar repositories, and it mirrors them. Delightful.
My phone's been in interplanetary orbit since I went to the Pyrenees two and a half weeks ago. Without it, life's been calm -- time to write, for example. But it's getting old, I might have to hoof it to Tarragona to retrieve my social contact device.
I bought two old albums today: more Cat Power (the covers album, which is astonishingly beautiful), and Yo La Tengo (And then nothing..., mellow, in a similar haunting vein, verging on mope). I just can't seem to put 2000 down. cd drome++; instead of swiping a barcode to listen like at FNAC, there you spin vinyl.
MediaLens' cogitations continue to inspire.
Finally, I desire to believe that the word "mindset" comes from the definition of "set" as "[d]irection or course; as, the set of the wind, or of a current." To me this is a wonderful image that some sailors I know might appreciate.
I have a bit of a writing backlog. Rather than edit edit edit, taking the moment out of whatever it was I was writing, I'm just going to dump a bit before writing something new.
I would like to make words about John Leonard.
I recently stole half a dozen back issues of Harper's from a friend's apartment in the states. It is my purloined word-horde of delight.
Their happiest turns of phrase are offered by Leonard's monthly book reviews. I imagine him as an eccentric spider in a multidimensional web, nimbly turning around newly trapped books in webs of their predecessors, decorating his subjects with perception. Generous, too, like a grandfather in his shop, talking out loud, telling old stories. Then he give you his tools, asks you to try your hand at the lathe or soldering iron.
(My grandfather was a spider, it make my eyes mist thinking of him, excuse me)
I'm growing a bit frustrated with Spain, on this my fourth anniversary of flying away from my previous homes in the states. Why can't I find tofu or decent sliced bread in the stores? Why is it that my schedule overlap with grocery stores is only 40 minutes per day? Why is it so difficult to find a café to hack in at three in the afternoon on a sunday? Not to mention the lack of greasy spoons, burritos, and proper sandwiches.
Say what you will about cultural relativity, but a grilled emmenthal-walnut-basil-avocado-mustard sandwich on hearty dark bread is objectively better than flaccid bacon and processed cheese on a dry baguette.
On the other side of the exaggeration, Barcelona is civilized in ways that American towns don't even know how to dream about. I don't miss the irritations of owning a car. I can bike everywhere in town. When I go out my front door, there are people walking the streets, strolling with and without purpose -- the liquid to the gaseous state of America. What is not here is the second-hand couch on the front porch, the rocking chair, the shed out back.
Apparently my happiness is entirely determined by home, food, and transportation. I fret insatiable.
Hacking, I take control of my life. Or perhaps the clause should be, "doing things I should have done a while back". I realized this the other day that after knocking down some bugs in guile-gnome, guile-lib, and g-wrap. Doing so lets me take care of email backlogs of bug reports, patches and questions I never got around to before, making me feel like I'm actually getting on top of my inbox, which is currently at best a minor form of guilt.
Speaking of guilt, I should mention something that people nagged me about for a long time, until apparently they gave up: the video archives for GUADEC 2006. Here is the situation. The raw recordings I have are of large chunks at a time (between 2 and 20 hours), and do not play properly in most players. You cannot seek in them. Why? Because I fucked up and recorded in too high a quality for the boxes we had for encoding. Secondarily, after we had to drop some frames, the encoders continued on as if frames had not been dropped, thereby ensuring that the archives have large synchronization problems.
At first I invested quite a bit of effort into trying to get these videos cut and resynchronized, writing two applications and a few hacks to a number of GStreamer elements. Last time I looked, those hacks were not working properly (segfaults, etc). It was depressing on the three levels of (1) I fucked up in the beginning, (2) I wrote large parts of the capturing software, and I didn't think it would discard the timestamps, and (3) the attempts at getting out ok-to-decent archives were failing also due to code I needed to write.
Given a limited amount of personal hack time, I chose to hack on my guile-related projects. Much more personal bang for the buck. While guilt might be useful on some occasions, and is only a two-key typo away from guile, in this case it was too much and I had to back off to retain my sanity.
So, um, my bad about that guys! I know it sucks. I've got some folks at the office interested in getting this job done so hopefully before the end of the year some decent archives will be out.
(Is there some kind of official body or church or something that one can go to for egoism problems? Looking over this next paragraph, I seem to need it.)
Going over the guile stuff I did, I have to say there is some really good work there. It's what continues to attract me to those projects. The texinfo parser I wrote for guile-lib is pretty hot, even given my proclivity for parsers. The lazy bindings work I did for g-wrap was all right. Mapping a GTK text entry to a scheme port wasn't so bad either. I dig on hacking it.
Distributed version control systems promote bitrot. With centralized systems, either your code is in or it's not: if you want it in, you have to get it in the maintained trunk. With decentralized systems, you can commit your code to some branch somewhere, and mentally mark it as done. This week I found patches over two years old lingering in one of my arch branches of guile-lib. Two years. People had been writing in to mailing lists to complain about it, and I was wondering why they didn't have the fixed version. Sheesh.
those wonderful songsters of the south
Sounds I have enjoyed recently: the tune Damaged Goods from Gang of Four, a greatest hits album of Arlo Guthrie, Gnarls Barkley's album, Twig and Mancini (Let's fucking brunch!). Also, did I mention Damaged Goods? Yes yes.
I'm your native son
I think I have finally been able to verbalize what I don't like about GNU arch. Enumerated: (1) Complicated offline operation; (2) Insane command-line interface (register-archive versus archive-mirror, commit -s or commit -m?, foo -h versus foo -H, etcetera); (3) Slow. There. There it is.
I recognize in myself an adherence to the known thing, a partiality about things I am familiar with. My family used to have a house in the mountains of Avery County, North Carolina, where we'd go to chill sometimes. Each trip we'd hike what I think was called Bellvue Mountain, which, as I was told, was the highest mountain in the county. I knew this, internalized it, told it to people I took up there. But in the end I realized what I knew was only my relationship to the mountain, not its relationship to the world. Sure it was important to me but I have no idea how it relates to anything else, without looking at it myself.
I mean to say that the only reason that I think that someone can stay with GNU arch is the familiarity, the affection for the tool, the idea that it's the tallest mountain in the county. If you actually walked around the area without preconceptions, I think that you would not end up with Arch. It was excellent at the time, but everything else is better now. Anyone that uses Arch now should try Mercurial, Git, Bazaar, Darcs; anything else. You'll be better off.
Advogato isn't as usual a haunt for me as it used to be, but I like to browse back occasionally, to see the comfortingly familiar and the fresh thoughts, without the pedestal effect of other aggregators.
Today was delightful. I was first greeted by Andy Tai's note that GNU arch 1.3.5 is out. I didn't know they were still kicking. I've been dealing a lot with subversion these days, and it's also comforting -- the same commands I always used work better now. Not exactly exciting, but my afán for exciting tools has waned, temporarily perhaps.
After the ever-abstruse nymia, perceptive-of-corporate-machinations robilad, we have the enticing dangling pointer that is apenwarr, ruminating on process and software. I'm not always able to dereference his allusions, but he's always a pleasant read, and has a corpus behind him.
There are more, old hands and new, but what is remarkable is that the advo community has maintained its quality over so long. So here's to advogato. May your community stay rich and accessible as the years roll on. Also, may your software see a series of pleasant, non-obtrusive upgrades.
When travelling, I have an enduring obsession with enumerating the ways that I have moved. So here we go: planes (7 thus far, in 9 airports), taxis, cars, motorcycle, sailboat, bike, buses, trains, metros.
If you are so disposed, you may choose to read "enduring" with the nonstandard pronunciation /ɪndi:rɪŋ/ (en - DEE - ring).
I spent the last week in San Francisco. It's a very civilized place. A lot of my friends from other threads in life have taken it as theirs. Besides the goodness of seeing my people, I really enjoy stepping into their lives, seeing the intersections between people and places.
Also, I would like to mention one thing. Burritoeater.com. Thank you that is all.
Various hacks on guile-gnome recently, none committed -- see we have a forest of GNU arch branches, and I can't remember how they work exactly. In the end I would have to evaluate arch as interesting, but confusing, and ultimately a problem. The need to explicitly mirror and create private branches (two things where there should be zero) for offline operation is very irritating. We have an innovative SCM setup, but I realized a while back I'm not so interested in trading pain for gain anymore. Gain-only need apply! That's why subversion is nice, and why bzr promises to be nicer.
In the short term however it seems I am stuck with pain for a while.