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

[Ondrej Certik]

On Wed, Sep 3, 2008 at 10:34 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I have couple more questions to the workflow:
>>
>> So you publish let's say 30 little commits in your branch. Stefan
>> reviews it, let's say he says the commits 15, 20 and 21 are crap and
>> you should rework it. :) So will you add commits 31, 32 and 33 fixing
>> the crap, or will you actually edit the commits 15, 20, 21 directly?
>> Does bzr allow you to easily delete the public branch and repost your
>> reworked 30 little commits?
>
> Currently we only use an all or nothing approach to reviewing and
> merging branches into trunk.  This does have the disadvantage that if
> you have a branch with many different commits, merging all of them
> could be held up by one or two that nee to be cleaned up.
>
> This is a reason to make more and smaller branches, rather than fewer
> larger ones (with more commits).
>
> I guess I usually work in a way such that in a given branch all the
> commits are related to each other in such a way that it wouldn't make
> sense to only merge some of the them.
>
> But, I think it is possible to do a merge of only certain commits.
>
> Does this answer your questions?

It answers a question, but not the one I asked. :) Sorry that I made
my question unclear, I'll try to ask it differently below.

>
>> Because you said you merge those 30 little commits into one or a few
>> commits, so people who pulled your branch will have mess in their
>> repos, right?
>>
>> I like the direct editing workflow, i.e. I also like to commit 30
>> little commits and then merge it in a few well polished patches, send
>> them for a review (e.g. push them into some branch), then fix things
>> couple times depending on the review and finally the commits go in the
>> main trunk. And I realized that mercurial is getting in my way in this
>> workflow, and we switched to git with Kirill (another sympy developer)
>> and it allows me to work in the way I described very easily and also
>> to push the reworked patches to the same public branch (removing the
>> old stuff).
>
> At this point, we are not working with directly with patches.  When a
> branch is ready to go - public or not, it is merged in.  I am not sure
> I am understanding your question now.

We both agree that one branch should only contain things, that are
related and it should go in as all or nothing.

Let's say you have 30 commits in the branch and let's say that it
doesn't pass the review, because it needs improving. My question is,
what will you do? Will you commit the improvement over your 30 commits
(e.g. just adding more commits to the branch, until all the code is ok
to go in), or will you try to fix some of the commits in the branch,
so that actually all of the commits individually are ok? (I know you
cannot just push there "individual commits", because they are related
with the rest.)

I don't know if I made it clear now. My question is if you try to make
each change (=each commit) ok to go in, or if you just try for each
new bunch of commits (=branch) to be ok to go in (i.e. some commits
can be crap, if they are fixed by later commits in the same branch).

Ondrej