[IPython-dev] Pull request workflow...

[Fernando Perez]

Hi folks,

thanks for the feedback! I just got a bit of time now...

On Mon, Oct 11, 2010 at 10:25 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>
>> So just to check.  Let's say you have:
>>
>>        A---B---C topic
>>        /
>>   D---E---F---G master
>>
>> You (Fernando) would prefer the pull request to be from a rebased
>> version of 'topic':
>>
>>                         Adash---Bdash---Cdash topic-rebased
>>                        /
>>   D---E---F---G master
>>
>> I must say, if it were me, I'd prefer the original in that case,
>> because it's a clearer indication of the history, and because rebasing
>> does have some cost.
>
> I agree with this.
>
>> The cost is that rebasing orphans the original 'topic' branch so that
>> it becomes actively dangerous to have around.   If you try and merge
>> 'topic' after you've merged 'rebased-topic' you'll get lots of
>> conflicts that will be confusing.   That means that, if you've put
>> 'topic' up on your github site, and anyone's fetched from you, then
>> you've got to track who fetched and warn them they are going to run
>> into trouble if they use anything based on it.
>
> Yes, rebasing definitely creates a lot of overhead in the form of
> extra branches that you have to manage. For new devs (even for me
> sometimes) that is a significant cost.
>
>> Well - anyway - you know all that - but I think - if you are
>> suggesting rebasing even for the clean 'coffee cup handle' type of
>> branches, that would be unusual practice no?
>
> 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.

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

Cheers,

f