[IPython-dev] branch management getting better...

[Ondrej Certik]

On Thu, Sep 4, 2008 at 8:27 AM, Stéfan van der Walt <stefan at sun.ac.za> wrote:
> 2008/9/4 Fernando Perez <fperez.net at gmail.com>:
>> On Wed, Sep 3, 2008 at 3:23 PM, Ondrej Certik <ondrej at certik.cz> wrote:
>>
>>> I am still trying to find the best workflow, but so far I like this: I
>>> commit very often and prepare something in my local branch. Then I
>>> rebase it in a couple of well documented nice commits, put it in some
>>> public branch (so that people can pull it) and ask for a review. Then,
>>> if I did a good job and the "fix_crap" commit (there is almost always
>>> some) is simple, I completely agree with you it should be committed
>>> after it. But if I did a bad job and the whole branch needs to be
>>> revised, or just more deep changes are needed, it's imho better to
>>> rework it. E.g. what happens in your case, if the branch is "not ok to
>>> go in", but the fix is not just some easy "fix_crap", but some
>>> fundamental problem -- you just start another branch and use the good
>>> ideas (patches) from the broken one?
>>
>> I actually do like the approach you describe, but as far as I've seen,
>> bzr isn't the friendliest to this type of workflow with frequent
>> 'history rewriting'.  It's my understanding that git is far, far
>> better suited to this approach.
>
> In bzr, it seems everything is just a plugin away:
>
> http://bazaar-vcs.org/Rebase

This is cool. Mercurial implemented rebase only recently, so it is in
the hg repo of hg, but not in any release.

Thanks Fernando for the comments, that's all I wanted to know. Btw,
this email by Linus is interesting with regards to rebasing:

http://kerneltrap.org/mailarchive/linux-kernel/2008/5/17/1852794

And see the emails around it. So as you can see it's still quite a hot
topic about the ideal workflow. Generally I'll try to learn from the
kernel developers, because they don't have just 5 or 6 active
developers, but hundreds of them.

Ondrej