[IPython-dev] Pull request workflow...

[Matthew Brett]

Yo,

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

Yes - we may differ in taste here - I find both of these to be fine.

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

Right - I guess all I was saying is that the contributors have to
remember more - i.e. - make sure that no-one could reasonably have
started to use one of your branches, make sure you delete them as soon
as they've been rebased and merged, and so on.  If anyone forgets or
doesn't know, then they are more likely to inject chaos than
otherwise.

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

Oh - ignore me - I've never made an ipython commit !

See you,

Matthew