[IPython-dev] how to contribute to ipython

[Ville M. Vainio]

On Thu, Jul 16, 2009 at 7:34 AM, Ondrej Certik<ondrej at certik.cz> wrote:

> I will hold my judgement, until I learn bzr good enough to do all the
> things that I ask below. :) But don't worry, I will not hold my
> opinions for myself after that. :)

You just can't take a git workflow and apply it to bzr. That is, you
are not supposed to even try it, because it'll leave you astray. Just
commit normally, then merge to trunk. There will be single commit for
merge, so you can think of that as your "squashing".

> ipython branch? E.g. not merge, but rebase. One way would be to export
> the patch to a file, delete the latest commit (is there some easy way
> to do that?), merge the main ipython branch and then manually apply
> the patch, and fix all collisions myself.

If you want this workflow (and are familiar with hg), perhaps
polishing the patches using mercurial queues would be an option?

> Those are things that I was doing in mercurial, and it was a pain, but
> doable, until I got fedup and switched to git. In git it's super easy.
> So now I want to learn how to do it in bzr, so that I can compare.
>
> Then I can say which of bzr, hg, git is the best. :)

As for how relevant this is to ipython, the VCS worklflow performance
is hardly a blocking factor in development (as you can see, bzr log
has ~ 1200 commits on mainline trunk), and other branches are not that
active either:

https://code.launchpad.net/ipython

In general terms, having observed people using hg and git, and having
used both myself, I would be hard pressed to suggest git over hg to
anyone. It seems to require lots of "support" (i.e. some git-savvy
person around to guide newcomers frequently), whereas hg and bzr are
pretty much learn-as-you-go affairs. Git is getting lot of popularity
and "buzz" at the moment, but I wouldn't be surprised by more and more
people getting disappointed with it as time goes on. In the meantime,
hg has extension support for 'bookmarks', 'collapse' (squash), rebase,
transplant etc., for people/projects that want those (in addition to
bzr-like merge-heavy worklflow with somewhat untidy version history).

-- 
Ville M. Vainio
http://tinyurl.com/vainio