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

Brian Granger ellisonbg.net@gmail....
Wed Sep 3 16:08:48 CDT 2008

> 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.)

Ahh, now I understand.  Our approach is that you create new commits
that fix the problems in the old commits.  There are a couple of
reasons for this:

1.  Commits serve as a full record of all the code that gets written -
good and bad.  If you are always completely covering up bad code, it
an hurt you.  Let's say there is a really subtle bug in a commit and
you spend a long time tracking it down.  You put in a test case and
all seems OK.  But if you erase the original commit, there is less of
a record about the bug that may help you or others in the future.  I
think it is much better to 1) have a commit that has the bug and 2)
have another commit that fixes the bug with a full description of the

2.  Sometimes code review requires making changes to code that spans
multiple initial commits.  At this point, I think it just gets
difficult to have a development model where each individual commit is
OK by itself.  Our development style to just too non-linear and
convoluted for this to be practical.  I suppose your style might fit
this model better - don't know though.

> 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).

We have a development model that allows for the following:

crap + crap + crap + fix_crap + tests = beautiful code merged into trunk

This seems more realistic than:

beautiful_code + beautiful_code + beautiful_code + tests = beautiful_code

Maybe once I become perfect, the second would work though ;-)


> Ondrej

More information about the IPython-dev mailing list