[
https://issues.apache.org/jira/browse/MATH-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15233313#comment-15233313
]
Rob Tompkins commented on MATH-1290:
------------------------------------
I think I would proceed in the following manner assuming we're trying to merge
Eric's {{feature-MATH-1290}} into the main apache commons-math {{develop}}
branch (or master either should work). From a clean directory on Gilles'
machine I would run the following:
{code}
git clone git://git.apache.org/commons-math.git
cd commons-math
git remote add ericbarnhill https://github.com/ericbarnhill/commons-math.git
git fetch --all
git checkout -b feature-MATH-1290 ericbarnhill/feature-MATH-1290
<<Make and commit any needed changes to the branch here>>
git checkout -b develop origin/develop
git merge feature-MATH-1290
<<This should open vi and allow a commit message>>
git push origin develop
{code}
The explanation of the mechanics at play here follows below. Pardon my
long-windedness.
----
It looks like to me that what we're trying to do here is get Eric's branch
{{feature-MATH-1290}} merged into the main repository's either {{master}} or
{{develop}} branch. At a quick glance, it appears that either are reasonable
choices, but for the exercise we only need one, so let's choose {{develop}}.
For the sake of discussion here, let's refer to Eric's repository
{{https://github.com/ericbarnhill/commons-math.git}} as {{ericbarnhill}} and
the apache repository {{git://git.apache.org/commons-math.git}}, to which
Gilles makes his commits, as {{upstream}}. Before going any further, we'll do a
quick overview on the way git (unlike subversion) can handle working with a
collection of repositories that are remote to one's machine. When we run the
command:
{code}
git clone git://git.apache.org/commons-math.git
{code}
what happens is two fold: (1) git copies the whole repository to your machine,
and (2) git creates a named reference of the location from which you copied the
repository, the default name here is "origin." Now, once working from the
directory into which git copied the files, presumably based on the command
above, {{./commons-math}} we can add more repositories that we wish to use for
collaboration each of which we can give a name. Let's take my current local
setup as an example, and consider the following commands run in succession,
knowing the my copy of commons-math exists in the location
{{https://github.com/chtompki/commons-math.git}}
{code}
git clone https://github.com/chtompki/commons-math.git
cd ./commons-math
git remote add upstream git://git.apache.org/commons-math.git
git remote add ericbarnhill https://github.com/ericbarnhill/commons-math.git
git fetch --all
{code}
What happens here is creates my repo locally, with it linked by default with my
github "chtompki" location. I then add other repositories from which I want to
work, namely {{ericbarnhill}} the name we've given Eric's repository, and
{{upstream}} the name we've given the main apache commons-math repo. Lastly,
I've run the fetch command to get all of the branches from each of the
respective repositories.
Now, we have quite the collection of branches. If we run the git list branches
command
{code}
git branch -a
{code}
we see a host of repeated branches. We should see most of our branches listed
in the form {{remotes/<name-we-gave-our-remote>/branch-name}}. For example we
should see the following occur some where in our list
{code}
remotes/origin/master
remotes/upstream/master
remotes/ericbarnhill/master
{code}
each of which represents the state of that branch in each location. Now to move
onto one of these branches, all we need run is:
{code}
git checkout ericbarnhill/master
{code}
and that puts us on the master branch of Eric's repository with the state that
it was in when we ran the {{git fetch --all}} command, but because it's a
remote reference, git will not let us commit to that branch. Thus we might want
to create a working branch from the remote branch, which we could do in the
following manner:
{code}
git checkout -b <branch-name-of-our-choosing> ericbarnhill/master
{code}
Now we are on a working copy of Eric's {{master}} branch and can work from
there.
> Additions to Complex Utils; creation of conversion methods between Complex[],
> double[], float[], and interleaved arrays
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: MATH-1290
> URL: https://issues.apache.org/jira/browse/MATH-1290
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: 3.5
> Reporter: Eric Barnhill
> Priority: Minor
> Labels: newbie, patch
> Fix For: 4.0
>
> Attachments: ComplexUtils.java, ComplexUtils.java, ComplexUtils.java,
> ComplexUtils.java, ComplexUtilsTest.java, ComplexUtilsTest.java,
> ComplexUtilsTest.java, ComplexUtilsTest.java, LaguerreSolver.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I propose to add several new methods to the ComplexUtils class enabling easy
> conversion between Complex[] arrays, real or imaginary double[] or float[]
> arrays, and interleaved complex double[] or float[] arrays. The last two in
> particular are beneficial to have for OpenCL implementations and the
> JTransforms library.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
