apt-xapian-index now comes with a query tool I've just uploaded a new version of apt-xapian-index to unstable. Now it comes with a little query tool called axi-cache. You can search this way:

axi-cache search foo bar baz facet::tag sec:section

In fact, you can use most of the things described here. You can then say axi-cache more to get more results, or axi-cache again to retry a search, or axi-cache again wibble wabble to add keywords to the last search. This allows to start with a search and tweak it. In order to work it needs to save the last search so again or more can amend it. Searches are saved in ~/.cache/axi-cache.state. You can search tags instead of packages by adding --tags. It will suggest extra terms for the search, and also suggest extra tags. It can even correct spelling mistakes in the query terms once the index has been rebuilt with this new version of update-apt-xapian-index. I need to thank Carl Worth who, with notmuch, reminded me that if I just build a nice interface on top of Xapian's query parser I go quite a long way towards making a Xapian database extremely useful indeed. axi-cache also integrates with bash-completion so that tab completion is context-sensitive to the command line being typed:

$ axi-cache search image pro
probability      process          processors       programmability  provides         
problem          processing       production       pronounced       proving  
$ axi-cache search kernel pro
problems     processor    production   proved       provided     
processing   processors   programming  provide      provides     

Thanks to David Paleino who wrote the bash completion script. Just for reference, this is the command line help:

$ axi-cache help
Usage: axi-cache [options] command [args]
Query the Apt Xapian index.
Commands:
  axi-cache help            show a summary of commands
  axi-cache search [terms]  start a new search
  axi-cache again [query]   repeat the last search, possibly adding query terms
  axi-cache more [count]    show more terms from the last search
Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -s SORT, --sort=SORT  sort by the given value, as listed in /var/lib/apt-
            xapian-index/values
  --tags                show matching tags, rather than packages
  --tabcomplete=TYPE    suggest words for tab completion of the current
            command line (type is 'plain' or 'partial')

If you install the package for the first time, you may need to rebuild the index by running update-apt-xapian-index as root before using axi-cache.

I blogged a fair bit about darcs some time ago, but since then I’ve not been able to get comfortable with the patch algebra’s approach to dealing with conflicting merges – I think mostly because it doesn’t provide a way for the user to instruct darcs on how to recover from a conflict and continue on. I’ve had a look at bzr since then, but it just feels slow, to the point where I tend to rsync things around instead of using it properly, and it just generally hasn’t felt comfortable. On the other hand, a whole bunch of other folks I respect have been a bit more decisive than I have on this, and from where I sit, there’s been a notable trend:

Keith Packard, Oct 2006

Repository formats matter, Tyrannical SCM selection

Ted Tso, Mar 2007

Git and hg

Joey Hess, Oct 2007

Git transitions, etckeeper, git archive as distro package format

Of course, Rusty swings the other way, as do the OpenSolaris guys. The OpenSolaris conclusions seem mostly out of date if you’re able to use git 1.5, and I haven’t learnt quilt to miss its mode of operation the way Rusty does. And as far as the basics go, Carl Worth did an interesting exercise in translating an introduction to Mercurial into the equivalent for git, so that looks okay for git too.

… or something like that… I planned to write a short note about how to start with using git-svn so I can provide a pointer to some of my colleagues. It turned out that git has too many nice features that you should be aware of. Hopefully my notes (now being a reference for myself as well, thx to gebi for all the help and feedback) are useful anyway. If you think something (more or less essential, or at least something most of us should be aware of) is missing: please feel free to mention that in the comment section of my blog entry, thanks. Disclaimer: I’m still happy with mercurial for what I - and we at grml in general - use it: linear, but anyway distributed development. git on the other hand provides some really nice features. Rebasing and branching with git is really great - so non-linear development just works. As usual: use the right tool for the right job. git is a bit complicate to use. Not only but especially in the beginning. On the other hand I’m not such a big friend of subversion. If you wanthave to use subversion (Graz University of Technology for example provides a svn service to their students and employees) but prefer to work with git instead you should be aware of git-svn. git-svn gives you bidirectional operation between subversion and git. First of all make sure you have all you might need when working with git. Make sure to use a current version of git (I’m refering to version >=1.5.3). Just execute the following command line on your Debian system to install all relevant packages:

aptitude install \
git-buildpackage git-core git-cvs git-daemon-run \
git-doc git-email git-gui git-load-dirs git-svn \
gitk gitweb qgit

Now let’s start with some general and basic configuration:

# Remove directories from the SVN tree if there
# are no files left behind, configure it globaly:
git config --global svn.rmdir=true
# Want some more global, personal git configuration?
for line in  
  user.name=Michael Prokop 
  user.email=foo@example.invalid 
  color.diff=auto 
  color.diff.new=cyan 
  color.diff.old=magenta 
  color.diff.frag=yellow 
  color.diff.meta=green 
  color.diff.commit=normal 
do
  git config --global $line
done

Check out man git-config for much more details about configuration options. First tip: set ‘g’ as an alias for git so you don’t have to type that much. I’ll write the long version in the following examples so copy/paste works for everyone. Make sure to use the short options of git itself as well: use ‘git co’ for example instead of ‘git checkout’. You can define your own aliases inside git as well - either manually in ~/.gitconfig or running something like:

git config --global alias.st status

Enough pre-configuration for now. It’s time to checkout the SVN repository:

# Check out the SVN repository and set 'svn/' as
# prefix for the branches:
git svn clone -s --prefix=svn/ \
https://svn.tugraz.at/svn/$project foobar && 
cd foobar
# Adjust svn:ignore settings within git:
git svn show-ignore >> .git/info/exclude
# List all branches:
git branch -a
# List all remote branches:
git branch -r
# Rebase your local changes against the
# latest changes in SVN (kind of 'svn up'):
git svn rebase
# Checkout a specific branch:
git checkout $branch

Ok so far? But what do we have to do if we want to work on the upstream source and are allowed to commit/push directly to the repository? Let’s see how to work on that without using branches:

# Hack:
$EDITOR foobar
# Check status
git st[atus]
# List diff:
git diff [foobar]
# Commit it with a commit message using $EDITOR:
git commit -a
# Now commit your changes (that were committed
# previously using git) to SVN, as well as
# automatically updating your working HEAD:
git svn dcommit

But what should we do if we do not have commit rights? Let’s create our own branch and send a patch via mail to upstream:

# Make a new branch:
git checkout -b mikas_demo_patch
# and hack...
$EDITOR
# Commit all changes:
git ci -a -m 'Best patch but worst commit msg ever'
# ... and prepare patch[es]:
git format-patch -s -p -n master
# Now send mail(s) either use git-send-email:
git send-email --to foo@example.invalid *.patch
# ... or if you prefer mutt instead (short zsh syntax):
for f in *.patch ; mutt -H $f

You got a mail from someone else and would like to incorporate changes from the attached patch in your repository? Just store the mail in a seperate mailbox (use save-message in mutt for example, keybinding ’s’ by default), then execute:

# Apply a [series of] patch[es] from a mailbox
git am /path/to/mailbox

Want to work on a seperate branch and rebase your work with upstream?

# First of all make sure to use recent sources...
# So pull when using plain git:
git pull -u
# .. or when using git-svn use:
git svn rebase
# Then create a new branch:
git checkout -b mika
# Hack:
$EDITOR
# Commit:
git ci -a -m 'Best patch but worst commit msg ever'
# Switch to master branch:
git checkout master
# Pull again when using plain git:
git pull -u
# .. or when using git-svn use:
git svn rebase
# Finally switch back
git checkout mika
# Now rebase it with plain git using:
git rebase origin/master
# ... or when using git-svn:
git svn rebase
# Now check out the last 5 commits:
git log -n5

Another branch-session might look like:

git co -b foo
$EDITOR
git ci -a -m 'foo changes'
git co master
git co -b bar
$EDITOR
git ci -a -m 'bar changes''
git co foo
git rebase bar
git log -n5
git st
git branch

Pfuhhh? Right. Now it’s time to check out another cool feature: git stash, which is just great when pulling into a dirty tree or when suffering from interrupted workflow. Demo:

git stash
git pull / fetch+rebase
$EDITOR # fix conflicts
git commit -a -m "Fix in a hurry"
git stash apply
git stash clear # unless you want to keep the stash

git reset rocks as well:

# List all recent actions:
git reflog
# Now undo the last action:
git reset --hard HEAD@ 0 

How to get rid of branches?

# Delete a branch. The branch must be fully merged:
git branch -d remove_me_branch
# Delete a branch irrespective of its index status:
git branch -D remove_me_branch
# Delete a remote branch:
git push reponame :branch

Repack a git repository to minimize its disk usage:

git pack-refs --prune
git reflog expire --all
git repack -a -d -f -l
git prune
git rerere gc

Use git cherry to find commits not merged upstream. Another really cool feature is the interactive rebasing: git rebase –interactive Make sure you are aware of gitk: … and don’t forget to set readable fonts for gitk, like:

[ -r ~/.gitk ]   cat > ~/.gitk << EOF
set mainfont  Arial 10 
set textfont   Courier 10 
set uifont  Arial 10 bold 
EOF

If you prefer a Qt based interface check out qgit. Useful ressources:

• Google Tech Talk about Git by Randal Schwartz
• Linus Torvalds’ talk about git (there’s a Transcript of the talk available as well)
• Public Git Hosting at repo.or.cz
• Git Cheat Sheet
• git workshop at metalab by maximilian attems (PDF) [local copy]
• git talk by Bart Trojanowski (PDF)
• An introduction to git-svn for Subversion/SVK users and deserters
• Git - SVN Crash Course
• A tour of git: the basics
• Everyday GIT With 20 Commands Or So
• A tutorial introduction to git
• Git User’s Manual
• Git Guide - SourceMage Wiki
• Git Quick Reference
• Kernel Hackers’ Guide to git
• GitFAQ
• madduck’s ‘Packaging with Git’ (Git for Debian packaging)
• git docs online (manual pages)
• #git on irc.freenode.net, #git irc logs
• archive of git mailing list
• GitWiki

Scott, I would have expected a little more from you than your previous post on why you chose bazaar! Update: my initial post was offensive towards Scott, so I edited it a little, following a good discussion with Scott via Email. Even though his post didn't make it explicit, his post was meant to be a reaction to someone else praising Git above everything else. Or, in his words:

You're responding with a defence of git because I posted a defence of bzr in response to championing of git.

I decided to leave most of the original post untouched, nevertheless, but please read it in this context. I guess the sensible conclusion is (as always): to each their own. Inline updates are enclosed in [brackets].

---

Git is less of a version control system than it is a filesystem and a means to communicate among developers, and when used in that sense, it's extremely powerful and intuitive to use. And it is also a version control system, like Bazaar. It's blazing speed isn't the only killer feature. By no means, however, is it "heavily optimised for the 'I only apply patches' development model, at the expense of ordinary development models" [anymore]. It also supports centralised workflows just as well as it supports distributed approaches, and you can switch between them [this is not really true when compared to how Bazaar mimiques CVS/SVN behaviour; Git cannot do that]. Here are the git commands needed to do the same things Scott showed off in your post:

$ cd myproject
$ git init
$ editor .gitignore
$ git add .    # git rm ...

Let's branch before we commit. checkout -b is a shortcut to create a branch (git branch myproject-foo) and immediately switch to it (git checkout myproject-foo):

$ git checkout -b myproject-foo
$ git commit

Git keeps all branches within the same repository and lets you switch between them. Now, that is a killer feature: whether I'm versioning code or stuff like webpages, I often have external pointers to my code. For instance, I may have libfoo as a sibling of foo-ng and the latter refers to libfoo in the Makefile. If I wanted to try a new approach in libfoo, I'd have to change foo-ng's Makefile to point to libfoo-newbranch instead, or juggle directories around. That sucks. With git, I just checkout a different branch in the same space:

$ git checkout master

And even better: if you don't like it, you could just as well copy the repository to create a separate (remote) branch from which you can later pull or cherry-pick changes to the main branch:

$ git remote add foo ../myproject-foo
$ git fetch foo
$ git merge foo/master

Now back to your steps, and I'll stick to the git way of branching. Note how git does not differentiate between pulling and merging in the sense that you do. If there are no local modifications, git just fast-forwards the branch with the commits on the master:

$ git merge myproject-foo

Even better, say you don't want the last two commits:

$ git merge myproject-foo~2

Unless git can fast-forward, it also treats a merge as a single commit and the ancestry information allows you to inspect its component commits just like you would. gitk is another killer feature, which I believe bazaar copied from git, just like the bazaar folks adopted the concept of rebasing, which basically lets you rewrite history quite freely, another killer feature (which can be quite badly abused if you don't know what you're doing). And then there is git bisect and git-svn and git filter-branch and git describe and git stash and gitweb and, and, and So if I compare the git commands I used to the way you used bazaar, I fail to see much of a difference. Do you? It is true that git comes with an astounding number of additional commands, most of which you never have to use, but which are available to the user [but its interface is a huge improvement over GNU arch, nevertheless, and if only because the commands are named more logically and revisions and branches do not have to adhere to one of the strangest syntaxes ever]. I don't deny that their sheer abundance is overwhelming and confusing at first (a general rule for Git for beginners seems to be just to ignore ever command with a hyphen in it). But once you get out of the newbie stage (it took me about two weeks, the duration of Debconf7 to become an acquainted git user; in fact, David Nusinow placed me among the ranks of real git wizards Pierre and Keith before the conference was over) arghs, I hate long remarks in parenthesis; once you leave the newbie stage, you'll appreciate all these commands, which make it really easy to script complex tools with git, making any plugin architecture pretty obsolete. Finally, I found myself trusting git way more than any other version control system I've tried simply because it's so transparent and you are allowed to edit stuff under .git, which is mostly plan text files (and objects, which you [could but] don't have to touch). It's transparent, and it stays true to the Unix way of letting small tools do their jobs instead of the monolithic approach. NP: Enchant: Tug of War Update: Carl Worth has a similar beef with people thinking that Git is too complicated and has ported a chapter from a book on Mercurial to Git to show how that's not the case. It's a good read. Update: Scott replied (quoted with permission), and I include my replies inline:

"I can tell you why you chose bazaar: because you had to, because you are being paid to use it."

Sorry, that just isn't true. I'm paid to lead the Ubuntu Desktop Team; this has nothing to do with version control, except that the various upstreams and packages use different systems.

I am sorry about this accusation. It was low.

You appear to miss my point about Git, or maybe I didn't make it strong enough. It's not that I don't understand it; it's that I had to take time and effort to understand it. And I've noticed that every reply to my post misses out the fact that with Git, you have to take action to ensure your changes are actually incorporated into the commit; either with git add or commit -a. This exactly the kind of anti-social behaviour that I have issues with.

Well, Git people call this a feature and it is very handy, but I see your point. There is no way to configure git-commit to always include -a, so you'll have to work around it:

git config alias.ci 'commit -a'

This creates git ci to do exactly what you want. You cannot overwrite commit that way though. But it could be trivial to add a configuration option to git-commit, if you think that the way that Git exposes the index is an adoption-stopper:

$ file -L =git-commit
/usr/local/bin/git-commit: POSIX shell script text executable

Your post also introduces yet more over-complication by demonstrating about making a branch (in an empty branch) before you commit.

Your post does the same ("A common operation is realising that the commit you re about to make should really go on a new branch for now"), which is why I did it. You don't have to do that at all.

(Side-bar: bzr's design also permits multiple branches within the same repository.)

So I read the manpage and found bzr init-repository, but no way to add a branch to an existing clone, and also no way to switch between branches within a clone. In your original post, you claimed: " Bazaar s command set works the way you do." Well, the way I work is by "switching" between or "checking out" a new branch in-place, but I could not trivially find the command to do this. This is probably because I have not invested enough time into understanding Bazaar, but isn't that what your claim is all about: that "[you] had to take time and effort to understand [Git]" and that Bazaar just works for you?

My post was why I choose bazaar, and why I have rejected other revision control systems that I have attempted to use.

So why did you post it? Surely because you wanted to express your preference over Git. In doing so, you made a couple of claims about Git which are simply untrue, which is why I replied. And the reason I replied is simply because other people who try to make a choice between Git and Bazaar may find your post and take away from it the information that Bazaar is superior to Git, which it is not.

I'm glad that you prefer a different system; but please don't insult me by suggesting that I'm being paid to use the one I prefer, or that I haven't bothered to learn one I'm "slagging off".

But you did slag Git in that you basically present its shortcomings side-by-side to Bazaar's greatness, which is a common PR/marketing thing to do. So just like I failed to create an in-place branch above because I did not bother to learn Bazaar, you did not bother to learn how to do with Git what you showed off with Bazaar, or else I'll have to assume you would not have written up the comparison as you did.

I have to use git as much as I use bzr, and I simply prefer bzr.

That was not the message I took from your original post.