It’s as though every other version control system I’ve ever used was created by people who were really into version control and Git was created by people who were really into hacking.
Fork me!
Pretty excited about this:
libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language with bindings.
Ruby and Python bindings are already coming along nicely.
I’ve been working with kneath on this pretty much since the day we started at GitHub almost a year ago. Not full time but whenever we could steal time away from other projects. We’re both stoked to have finally shipped it.

I wrapped the original blog post draft with this sentence:
Pull requests elevate the collaborative aspects of development to creative works in their own right. We can’t wait to see where you take them!
We ended up striking it — a little too floaty for a product/feature announcement. I believe every word of it, though.
Great advice for commit message formatting. It’s absolutely vital that the first line not exceed 65 characters (50 is suggested and good practice). Browsing around github.com, I see a ton of commits with an entire paragraph on the first line and it drives me crazy. This destroys git log, tig, git format-patch, and a lot of other commands that use the first line as a short message — even git pull shows it when the HEAD moves.
It’s a commit list (git log --online --reverse <start>..<end>), a rolled up diff + diffstat (git diff --stat <start>...<end>), and commit comments all on one page. Here it is in action showing all changes between the Sinatra 0.9.4 and 1.0.a releases:
Dogfood never tasted so good. We’ve been incrementally using and developing and using and developing this thing for a few months now. It’s become a core part of our code review process. I’m extremely happy with how it turned out.
Working with Scott is such a huge honor. I don’t even have words to describe it, really. He’s a class act. You get a glimpse of it in this interview.
He even lets loose some GitHub secrets:
At GitHub we don’t have a project tracker or todo list – we just all work on whatever is most interesting to us. No standup meetings, burndown charts or points to assign. No chickens or pigs. It’s sort of the open source software style of business – everyone itches their own scratch. Inexplicably, it works really well and keeps everyone engaged, new features appearing quickly and bugs fixed rather fast. No managers, directors, PMs or departments – and it’s the most agile, focused and efficient team I’ve ever worked with. Maybe we should write a book about it.
Do whatever you want. Do it now. Don’t fuck around.
Benjamin Pollack — one of the guys that helped build Fog Creek’s Mercurial based source control system, Kiln — pleads for Git and Hg folks to stop bickering over stupid shit and team up to go after the massive number of Subversion/CVS holdouts.
I can confirm one of his points:
It’s easy, in the yin/yang of Hacker News and proggit, to forget that most developers are not even aware of what DVCSes are or what they do. Yeah. Sounds crazy, I know, but trust me on this.
This is true. My second day on the job at GitHub was spent at the Zend PHP conference. Maybe 10% of the people we talked to had any awareness of DVCS at all, and a big chunk of that 10% hadn’t used DVCS seriously on a project. This was six months ago.
For most popular programming language communities, I’d put the percentage of developers that really understand DVCS under 1%.
Aristotle explains how he uses git’s index and how it makes git unique among VCSs. I’ve raved about git’s index before in The Thing About Git. It’s great.
defunkt’s hub is a command line utility that adds GitHub knowledge to git. Sweet. It expands GitHub repository references so you can do stuff like: git clone defunkt/gist, git remote add bmizerany, etc.
I recently started a repository for my dotfiles, shell environment, vim config, and utility scripts. As of right now, I’m about 25% through all of the stuff in my $HOME — it should all fill in shortly.
Turns out
tig, the ncurses front-end to git,
is all kinds of customizable. Quick tip: set the author-width
to 5 or less and author names are abbreviated to initials:
$ cat <<E > ~/.tigrc
set show-date = no
set author-width=3
E
$ tig
RT harmful specs - disable them
KN [defunkt/master] I shine the shoes around here
CW don't let daemon serving ruin the public / private flow
CW ensure the listeners are notified, just in case
CW add "open sourced" event
CW Turns out we're still stuck on 1.0
CW let's try this again
CW allow overriding of the queue during job creation
Boom.
We’ve been getting a decent amount of PR-ish type coverage since the commercial launch but I still say blog posts like these are infinitely more interesting:
Remember when microwaves first hit the scene and people couldn’t believe how fast they could ‘deploy’ a meal? Yah me either, but the microwave changed the game big time.
And, unlike the microwave, Heroku doesn’t make your apps taste like cardboard :)
tl;dr — that’s why it’s awesome.
Ruby based continuous integration server that rocks. Built on Sinatra and DataMapper. Painless setup, beautiful web UI, hooks up to GitHub. I wish I’d went and looked at this earlier.
Aristotle Pagaltzis shows a pretty crazy technique for splitting a single git commit into multiple separate commits using an interactive rebase and successive checkouts on the same branch. Interesting approach. I usually pop the commit off into my working directory with git reset HEAD^ and then use multiple iterations of git add --patch + git commit until my working directory is clean again.
Tom Preston-Werner on how GitHub came into being and leaving Powerset after the Microsoft acquisition: “When I’m old and dying, I plan to look back on my life and say ‘wow, that was an adventure,’ not ‘wow, I sure felt safe.’”
Very interesting alternative to git submodule, especially in “vendor branch” type scenarios. The other project is merged into yours at a specified prefix and can be updated with a simple git pull.
I threw this together a few weeks ago and now I’m not sure how I lived without it now. I know you people have cool bash/git hacks sitting in your ~/.bashrc — hand them over.
Sam Ruby on how DVCS + mailing list has removed the need for bug tracking systems on some projects. I’m feeling a similar pull in my own work.
If you move the slides quickly, it feels a bit like playing Desktop Tower Defense.
Justin French: alias push?='git cherry -v origin' — beautiful.
Interesting thread wherein Linus describes the need for various types of Git workflows for leaf developers vs. maintainers. Lot’s of talk about the pros and cons of rebasing in different situations.
Oliver Steele details his (and others’s) Git workflow with a bunch of illustrative graphs, emphasizing one of my favorite aspects of Git: There’s More Than One Way To Do It.
A gem for your project is automatically built each time the project_name.gemspec file is changed on your master branch.
All manners of good stuff here.
Now this is the kind of direction I hope to see GitHub and Gitorious go in the future.
A nice solution to “The Tangled Working Copy Problem” for VCS’s that don’t allow you to pluck out portions of a working copy to commit. Allows editing the diff that’s about to be committed.
There are some great tips for owning your local workflow in here.
I can’t say whether this is an accurate description of hg but he nails a lot of the things that makes git interesting, IMO.
I’m a bzr refugee in Git-land, myself.
Bill de hÓra gives some reasons for using a distributed VCS even when the downstream repo is non-distributed.
Okay, I’ve read about five of these articles purporting to explain Git’s internal conceptual framework. This was the first that really made things click in any significant way.
More praise for GitHub from a small team of Django hackers that built a site in three hours on one night with a little help from git…
A quick script I threw together to convert simple bzr branches to git repos. Requires git, bzr, and rsync.
“The last features standing get re-integrated into another branch known as the ‘trailer park’ to try to find a new life for themselves. Note that ghetto is frequently called ‘trunk’, and the trailer park something like ‘releng’”
Huge thanks to al3x for the invite. I’ll be writing up my experience over the next week or so.
Seriously interesting web based git browser and collaboration tool from the folks at Engine Yard. If anyone has a spare invite laying around, hook me up: rtomayko@gmail.com. I have a bunch of stuff sitting in bzr repos that I’d like to flip over to git.
Finally: “this manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git.”
There’s some good questions here. I’ve been running into a few of the same issues while experimenting with moving some of my bzr projects to git. Can one of the git pros out there have a look?
Wherein Aristotle convinces me to seriously consider moving my experimental bzr projects to git. I’ve seen the content vs. file tracking argument before but never really understood what the actual impact of this difference was.
“…. But after closely studying Git I’m a little bit awestruck; Torvalds is a frickin' genius, a true visionary, and somehow managed to just "get it” and instantly, in a flash of insight, come up with “the solution” for version control."