Hi Fernando and everyone, <br><br>Since we talked about this just yesterday in the context of nitime, I thought I would pitch in with one more thought:   <br><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Do we think balance is the following?<br>
<br>
- From the proposer&#39;s side, rebase *before* you make your first pull<br>
request.  After that, don&#39;t worry too much about any more rebasings.<br>
That will give a reasonably clean starting point for the review, as<br>
well as ensuring that the branch applies cleanly.  For developers<br>
(like Min points out with his example) who are very comfortable with<br>
rebasing in-review they can do so (like he did), but we shouldn&#39;t<br>
*ask* that they do.<br>
<br>
- And no rebasing from the committer&#39;s side like I originally<br>
proposed, except in cases where significant criss-cross merges need to<br>
be cleaned up.<br>
<br>
And we could make the idea of an initial rebase 100% optional, only to<br>
be done by those who feel comfortable with git.  I know the word<br>
&#39;rebase&#39; scares many new to git, and we don&#39;t want to put artificial<br>
barriers to contribution.  So it may be best to say that these are our<br>
suggestions for more advanced developers proposing complex merges, but<br>
that we will still accept any non-rebased pull request, as long as it<br>
doesn&#39;t merge *from trunk*.<br>
<br></blockquote><div><br>In principle, this sounds balanced and good to me. However, after reading the first email in this thread, I 
realized that what I hadn&#39;t considered when we talked about this yesterday, is the difficulty posed 
to code reviewers by the messed-up history caused by merging into a 
branch, rather than rebasing. <br><br>What I am currently thinking is that the 
reviewer can decide whether the merge causes the history to be 
so messy such that they cannot understand and review the commits in the pull request. I 
think that this makes sense, because if the history is messed up so 
badly that it can&#39;t be easily reviewed now, it will only be more difficult to understand in a couple of months, or in a year. This would be equivalent to some of the decisions that reviewers make about code style and clarity. You might decide that the code proposed is just too riddled with stylistic eye-sores to be merged (even if it does what it is supposed to do) and ask a contributor to clean up the code before pulling. On the other hand, you might decide to let a couple of eye-sores slip by, in order to make a contributor&#39;s life a bit more easy. I think that the same should apply to the git history that would result from the pull. If it causes a slight criss-crossing in the history, that is easy enough to figure out, let it by. If it actually makes review of the code difficult, send a message to the contributor, preferably with some direction on how to fix it and how not to do it again, much the same as you would for a contribution that contains stylistic errors. Just a thought.   <br>


<br>Cheers, <br><br>Ariel <br>  <br clear="all"> 
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
How does this sound for our final take?<br>
<br>
Cheers,<br>
<div><div></div><div><br>
f<br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ariel Rokem<br>Helen Wills Neuroscience Institute<br>University of California, Berkeley<br><a href="http://argentum.ucbso.berkeley.edu/ariel" target="_blank">http://argentum.ucbso.berkeley.edu/ariel</a><br>