watching the founder of github talk about git.

https://www.youtube.com/watch?v=aolI_Rz0ZqY

here is what I learned:

Just announced is release of Git version 1.7.2.

Scanning through the ReleaseNotes the following look interesting:

• git -c var=val will override config
• git show :/pattern now uses regex
• git no longer squelches if it doesn’t find .git (useful when using in PS1)
• git checkout --orphan name makes a new root branch (no parent)
• git cherry-pick can now be given a list of refs
• git log --decorate learned to colour more things

While preparing for my [Git]{tag/git} Workshop for Flourish Conf, I thought about serving files over http directly out of a git repo.

Here is a short shell script that I came up with: git-serv.cgi.

It takes request URLs like http://domain/examples/dir/file and looks up the objects in a bare git repository in /home/git/examples.git. It looks only on the master branch, and nothing is ever checked out. If it finds a tree object, it prints the file listing at that point in the tree. If the object is a blog, it dumps the contents. Otherwise some error is reported.

Here is [yet another]{zsh-git-prompt} update to the series. I’ve updated my git prompt again, now using the zsh 4.3.7 built in vcs_info module. This time the motivation came from Zsh Prompt Magic article. Here is what it looks like now:

Everything is now self contained in one file: S60_prompt. Grab it and source it into your zsh config.

The features are:

• name of current branch,
• git repo state (rebase, am, bisect, merge, etc),
• markers indicating staged/unstaged changes,
  • little 1 after branch name indicates dirty working tree,
  • little 2 after branch name indicates staged changes,
• highlight depth decended into the repository on the right,
• show failure of commands via prompt background change,
• show command/insert mode when using vi mode (set -o vi).

I am experimenting with a new workflow to help solve the problem of lost work between commits. As described [in my previous post]{20091104194146}, there are already several ways to deal with keeping track of frequent edits. The only problem is that they all involve dedication and extra effort.

A few days ago a buddy, Jean, had stumbled into a problem caused by infrequent committing to his git repository. Committing after the feature is implemented is common when working with tools like SVN… but we have multiple workflows available to us under git to manage frequent commits.

I got playing with git log and ended up creating this alias:

[alias]
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative

Which adds a git lg command that is a prettier version of git log --oneline.

I have recently been asked to revive an old project. Way back when I used to use bk for tracking changes. But today, I don’t even have a working bk tree.

Moving the history to git is easiest done by taking the tarballs I’ve published and creating a commit per tarball.

Below is a simple script that will do just that.

Someone on the Git LinkedIn group asked “why pick Git?”. I started writing a response on LinkedIn but quickly realized I had more to say on the topic than I’d care to leave behind closed doors of LinkedIn.

If you already use Git, none of the stuff I talk about below will surprise you. But if this sparks your interest see my Git talk.

It should be of no surprise to readers of this blog that I am a fan of Git. If you know me, you will also know that I am no fan of Bzr.

I was working on something today and wanted to export a patch… you know, like git format-patch does. Well, bzr does not seem to have an equivalent.