[IPython-dev] Pull request workflow...

[Brian Granger]

>> 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
the following:

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
comment/edit/rebase cycle.

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.

I agree.

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

For simple pull requests where there are no additional commits, I
think rebasing is just fine.  It is mostly in the more complex
review/commit/rebase cycles.

Cheers,

Brian

> Cheers,
>
> f
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com