[IPython-dev] Pull request workflow...

[MinRK]

On Tue, Oct 12, 2010 at 08:59, Brian Granger <ellisonbg at gmail.com> wrote:

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

3. is not actually true.  You can rebase and push on top of the old branch,
preserving the pull-request/discussion. I did this with some of my branches
in pyzmq.  The commits change, so the ordering ends up different, but it
certainly works.  And, if you want to preserve the old commits in their
original state, you can check out 'mybranch' and push it as 'mybranch-save'
before rebasing.

See http://github.com/zeromq/pyzmq/pull/31 for what a pull review looks like
where a rebase has happened in the middle.  What's lost is the ordering
relationship of commits/comments, which is certainly not ideal, but is quite
manageable for small feature branches.

-MinRK



> 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
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101012/dab0ec66/attachment.html>