Comments on: Git for Gnome, Take Two

By: shaunm

shaunm — Wed, 19 Sep 2007 15:22:20 +0000

Gábor, I see your point. I was just passng along what the majority of commentors seemed to think was a good idea. I think I’d need time with a larger project with more developers before I could decide what I like more.

By: shaunm

shaunm — Wed, 19 Sep 2007 15:18:08 +0000

Gustavo, I think you just sold me on git. I absolutely hate that branches and tags in SVN are just directories. In my first git blog post, I said that I actually like CVS more than SVN. That’s why. I can’t tell you how many things I’ve run across that are harder (or even impossible) because SVN doesn’t have real branches and tags.

By: Gábor Farkas

Gábor Farkas — Wed, 19 Sep 2007 09:42:23 +0000

i’m sure git-rebase is useful, but i don’t think it should be always used.

imho it’s much better, that when you start to work on a feature, then you create a branch, and work (commit) in that branch. when finish the feature, and only then, only when all your commits are done, start to worry about how to merge this branch back into the main branch.

and when you are merging it back, you can do it either by rebasing, or by simply merging it.

i think there is a key difference between svn/cvs and git/hg/bzr:

in svn/cvs, you usually update before you commit

in git/hg/bzr, you just commit everything you need, and then at the end (after all the commits are done), you merge your work into the main branch.

so maybe for someone coming from svn/cvs, the rebase-frequently approach seems more familiar.

git-rebase is nice if you want to have a linear history. but if you don’t care about linear history, i don’t see any reason to use it.

(of course, this all is about the case when you work on a project whose main branch is also in git. if you are trying to commit your changes to svn using git, then you must rebase)

By: Gustavo Carneiro

Gustavo Carneiro — Tue, 18 Sep 2007 23:43:44 +0000

bzr deals with branches much more intuitively: a branch is a directory, period. When you look at a bzr tree you know it does not contain hidden branches. It’s just like something I liked when switching from CVS to Subversion, that branches suddenly became less “magical” and been given a more physical appearance. bzr picked up the branch-is-directory concept very nicely, while git decided to go for hidden branches.

Now, of course that if you want to have multiple branches and save some disk space, bzr supports it as well. You create a “repository”, which is just a parent directory, with all branches of the same project as subdirectories of the repository. Then automatically bzr saves space by only saving the differences between different branches.

Not that I hate git, but bzr is just much better usability wise.