[IPython-dev] branch management getting better...
Thu Sep 4 01:49:09 CDT 2008
On Thu, Sep 4, 2008 at 8:27 AM, Stéfan van der Walt <firstname.lastname@example.org> wrote:
> 2008/9/4 Fernando Perez <email@example.com>:
>> On Wed, Sep 3, 2008 at 3:23 PM, Ondrej Certik <firstname.lastname@example.org> 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:
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:
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.
More information about the IPython-dev