Is it easier to manage code with Git or Bazaar?

I think it depends on your personal taste - there are arguments for both of them. I have used bzr extensively for personal projects for a couple of years, since the 0.8 days, but I have switched to git last year, and never looked back, at least for source code management.

I am too lazy to rewrite my own impression, but to sum it up:

• bzr works more consistently across platforms
• bzr is more discoverable (if you are given the tool wo any documentation, any semi-competent user will be able to use bzr, that's not so true with git)
• bzr is easier to extend in an API way, git is easier to extend in a unix way (pipes)
• git is immensely more powerful IMHO; in particular, I am convinced that their approach for rename handling, and content tracking is the right one for many cases
• the bzr revno system is not good IMHO. It looks simpler, but it is deeply confusing once you start having many branches and change the mainline.

It's going to come down to personal preference, plain and simple.

I use Bazaar and find it extremely easy. The staging area concept in Git gives some nice flexibility but it also adds complexity. You can quite easily manage code in Bazaar with something like 4 commands (add, commit, merge (maybe push/pull) and log or qlog), and you only need merge if you want multiple branches.

Usually Bazaar seems to do the right thing. I've never really had a problem with it doing something stupid or letting me do something stupid.

I suppose you also read Bazaar vs. Git article, but in the end, it all comes down to what you are looking for in term of "feature-rich code management".

• If, by code management, you are referring to file (and directories and renaming), go with Bazaar.

• If, by code management, you are looking at content management, Git is designed to manage just that (the staging area, for instance, allows you to record what current content you want to commit, even though you have already begun to make some large modification you end up not wanting to commit in the current branch)

To be sure, re-read Linus's original vision for Git (back in April 2005). If you do agree with it, chances are Git will deliver what you want. In short:

• very simple model (blob-tree-commit-tag)
• no metadata added (for tracking renaming for instance)
• "strong" principles like:

  • "files" do not matter. The only thing that matters is how "content" moved in the tree
  • You have an SCM that tracks what changed at the only level that really matters, namely the whole project. None of the information actually makes any sense at all at a smaller granularity, since by definition, a "project" depends on the other files, or it wouldn't be a project

That "all project" notion is actually a strength and a limit for Git in term of project management: you should not seek to put everything into one Git repository.