Echoing a post: bzr vs. git

[David Cournapeau]

Adrian Wilkins wrote:
> I think it would actually be beneficial to support both models ; as it is,
> making a new branch on the spur of a moment can consume a lot of disk
> (and more
> importantly, the time to copy the files), as you point out later on.

Yep, but again, speed is not even the main issue. For example, let's say
you are in a directory dir1 in b1, and you realize you need a new branch
b2. In bzr:
    - cd shared_repository_dir
    - bzr branch b1 b2
    - cd b2/dir1

In git (anywhere in the repo)
    - git co -b b2

When dir1 is deep down in your repository, that matters quite a bit in
my opinion. When I say git branch are cheaps, I mean both in term of
resources (disk and CPU), but in term of keystrokes/commands (e.g. UI)
as well. Creating, switching, deleting branches is as easy as it can get
under git. It is really hard to go back to bzr after this when dealing
with branches IMHO.

> Both have means of querying for revisions. If there's a particular
> query in git
> that you miss in Bazaar, please mention it ; someone may like the idea
> enough to
> implement it.

Not strictly about revno per se, but somewhat linked: those are things I
really like in git (note that it is biased toward someone using it to
track patchs above a svn repository, I don't claim it shows a typical
git usage):
    # log commits in b2 not in b1
    git log b1..b2
    # log commits in b2 not in b1 which concern only dir1
    git log b1..b2 dir1
    # Diff between b1 and b2 in directory d1
    git diff b1..b2 dir1
    # I really like this one, in particular when giving a path:
    # useful to review a patch in a branch: this gives the number
    # of insertion/deletion per changed file
    git diff --stat b1..b2 dir1

Notice how having several branches in one repository has a strong
advantage on the UI side, because branches and directories are not the
same. I don't know how to do that in bzr (maybe some queries are even
not possible at the moment, like the stat thing).

Another thing I found useful was git diff --color-words, which
highlights only the different words in a diff, but this could be done
with bzr, at least I don't see why it could not.

Those are about the main commands I am using with git (with the
commit/push/pull + rebase, but there is nothing particular about it
compared to bzr, at least from a UI POV).

>
> > Scriptability
>
> - From a Windows point of view, I find the commands that have XML
> output options
> are very scriptable on my working shell of choice, which is Windows
> Powershell -
> since you can treat XML as an object in PoSH, you can do stuff like
> the script
> below [1] ;
>
> I periodically attempt to get Bazaar to run under IronPython. Aside
> from the
> possibility that IPy will increase performance, I think having Bazaar as a
> Powershell snap-in would be marvellous because of all the tricks you
> could do by
> passing objects around the pipeline. Traditional pipelineing on
> Windows sucks
> because fork() is so costly. Being able to script Bazaar with Python is
> advantageous on Windows for this reason also.

Yes, more generally, windows support is a very strong advantage of bzr.
I did not mention it, because I was assuming it was obvious to the
expected audience of my post (which was not bzr ML :) ); but in a more
general context, it is not obvious I guess.

For me, knowing that git works on windows without git is enough; I may
be weird, but when I have to deal with windows (which I do quite often:
I am the windows release manager of numpy/scipy), I just use the command
line version of svn. I can't stand tortoisesvn.

>
> One of the core design criteria for SVN was always that the output
> should be
> easily parseable for scripting 

I would say it is a strong UNIX feature. I think it is safe to assume
Linus likes UNIX design :)

David