[IPython-dev] Pull request workflow...

[Fernando Perez]

On Tue, Oct 12, 2010 at 12:12 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Do we think balance is the following?
>
> - From the proposer's side, rebase *before* you make your first pull
> request.  After that, don't worry too much about any more rebasings.
> That will give a reasonably clean starting point for the review, as
> well as ensuring that the branch applies cleanly.  For developers
> (like Min points out with his example) who are very comfortable with
> rebasing in-review they can do so (like he did), but we shouldn't
> *ask* that they do.
>
> - And no rebasing from the committer's side like I originally
> proposed, except in cases where significant criss-cross merges need to
> be cleaned up.
>
> And we could make the idea of an initial rebase 100% optional, only to
> be done by those who feel comfortable with git.  I know the word
> 'rebase' scares many new to git, and we don't want to put artificial
> barriers to contribution.  So it may be best to say that these are our
> suggestions for more advanced developers proposing complex merges, but
> that we will still accept any non-rebased pull request, as long as it
> doesn't merge *from trunk*.
>

Actually, a comment in this article about the PostgreSQL migration
from CVS to git:

http://lwn.net/SubscriberLink/409635/11a5197ddb2c46b8/

makes a good point in favor of my original requirement above:

"""
everything that you want integrated into the main repository has to be
rebased on the main repository branch on which you want it integrated.
This is to keep conflict resolution with the developer of the code,
the one who actually know how to fix the conflict, rather than with
the integrator.
It keeps integration cost very low and also keeps at linear history,
which is again perfect for keeping features (consisting of multiple
commits) together, which is again for for all kind of other things
like bisecting and reverting.
"""

By asking that upon pull request, the requester's tree is rebased, any
conflicts will be fixed first by the requester.  This makes total
sense, and will ultimately save everyone involved (requester and
reviewers/committers) time.

So unless anyone disagrees, I'll go with that approach when I write up
our guidelines.

Cheers,

f