[IPython-dev] how to contribute to ipython
Thu Jul 16 12:28:54 CDT 2009
> Right, thanks for this. Now let's say you tell me to move the function
> to some other file. I go to the set_trace branch, move the function.
> Now what -- is there a way to fix the latest commit? Or do I need to
> commit one more commit? What if I have to fix the 3rd commit from the
> top? Is there a way to do it?
You just keep committing. Our philosophy at this point is that all commits
are worth keeping as it shows the logic of how things were developed. Often
times, it is useful to see that logic looking back as it allows you to see
what was tried and why it needed to be modified and how it was modified.
With git rebase, you only see the final result (which I agree is very
clean). The review system on launchpad actually works pretty well with this
"just keep committing" approach.
Now, what if I want to rebase my branch on top of the (updated) main
> 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.
Definitely too painful. Just keep committing.
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. :)
If you like to rebase, you will NOT like bzr.
PS - even though I *really* like git, I agree with Ville that it is more
complicated to learn and you have to use it often to keep it in your head.
bzr is simple enough that I can step away from it for 3 months and when I
come back, I remember everything. With git, after even a week away, I have
to start digging in the docs again.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev