[Numpy-discussion] Merging the refactor.

Charles R Harris charlesr.harris at gmail.com
Thu Nov 11 20:08:50 EST 2010


On Thu, Nov 11, 2010 at 5:48 PM, Pauli Virtanen <pav at iki.fi> wrote:

> On Thu, 11 Nov 2010 16:37:53 -0600, Jason McCampbell wrote:
> [clip]
> > We will take a look at this and the script.  There is also a feature in
> > git that allows two trees to be grafted together so the refactoring will
> > end up as a branch on the main repository with all edits.
>
> Yes, this is pretty much what the script does -- it detaches the commits
> in the refactor branch from the Git-SVN history, and reattaches them to
> the new Git history. This changes only the DAG of the commits, and not
> the tree and file contents corresponding to each commit.
>
> (Git's graft feature can only add new parents, so filter-branch is
> needed.)
>
> > My hope is that we can roll all of our changes into the main
> > repository as a branch and then selectively merge to the main
> > branch as desired.  For example, as you said, the IronPython
> > changes don't need to be merged immediate.
>
> I'm not sure if we should put development branches at all in
> the main repository.
>
> A repository like
>
>        github.com/numpy/numpy-refactor
>
> might be a better solution, and also give visibility.
>
>
I think that is right. The problem in merging stuff back into numpy from
there will be tracking what has been merged and hasn't and consolidating
things up into logical chunks. I'm not sure what the best workflow for that
process will be. As to the first bits to merge, I would suggest the tests.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20101111/10345d18/attachment.html>


More information about the NumPy-Discussion mailing list