[IPython-dev] Pull request workflow...
Tue Oct 12 10:59:41 CDT 2010
>> I know some projects like to rebase absolutely everything to have a
>> perfectly clean DAG. I don't feel like way and think the non-rebased
>> merges of coffee cup handle branches is just fine.
> Those are valid points. Let me try to clarify my perspective and why
> I suggested the rebasing. Compare the two screenshots:
> - http://imgur.com/nBZI2: merged branch where I rebased right before pushing
> - http://imgur.com/7bNOy: merged branch (yellow) where I did NOT
> rebase before pushing.
> I find the former much easier to follow than the latter, because all
> related commits are topologically together.
Definitely, but I do agree with Hans that this is really a problem
with the viewer, not the DAG itself. But, I definitely agree with you
that the rebased version is much cleaner.
> These branches aren't meant for third-parties to follow, since they
> are being proposed for merging into trunk, so I don't see the rebasing
> as an issue fort third-parties. In fact, even without rebasing,
> following these branches is never a good idea since people are likely
> to regularly prune their repo from obsolete branches (I know I do, and
> I've seen others do it as well). So I think for these types of
> branches, the argument of possible headaches for downstream users of
> the branches isn't very compelling.
I don't think the cost of rebasing is something that users/third
parties pay, but rather a cost that we, as developers pay. Consider
1. I work in branch foo, rebase it on top of master and then post on
github as a pull request.
2. People comment on the work and I have to make additional commits to
address the comments.
3. If we always try to rebase, I have to create a *new* foo2 branch
that has my recent commits rebased and post that to guithub. But
because it is a new branch, I have to submit a new pull request and
the discussion has to continue in a manner that is disconnected from
the original foo pull request.
4. This creation of new branches has to be repeated for each
This is a significant cost for developers, and I simply don't think it
is worth the effort. Not to mention that creating/deleting lots of
branches is error prone.
This is not to say I don't think that sometimes rebasing is a great
idea. It definitely is. But, I think we want to continue to use
non-rebased merges as a part of our regular workflow. I should say
that if rebasing didn't have this extra cost for developers, I would
be totally fine with it being the norm in most cases.
> I also don't think the rebased verion is a much less clear reflection
> of the original history, as all commits in the rebased version retain
> their original message and timestamp, so one can easily see when
> things happened.
> But if everyone prefers the alternative, I won't push particularly
> hard in this direction. I think that in this instance, making the
> group happy is more important than making me happy :) I'd just like
> to understand what actual downsides you guys see in rebasing *in these
> specific circumstances* (I'm not advocating rebasing trunk, for
For simple pull requests where there are no additional commits, I
think rebasing is just fine. It is mostly in the more complex
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
More information about the IPython-dev