[Math] RNG refactoring

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Math] RNG refactoring

Gilles Sadowski
Hi.

Last week, and just now, I've pushed local branches that handle
the following issues (and others, either related, or set to
"Won't fix [in current code]" in JIRA[1]):

  https://issues.apache.org/jira/browse/MATH-1335
  https://issues.apache.org/jira/browse/MATH-1336
  https://issues.apache.org/jira/browse/MATH-1337
  https://issues.apache.org/jira/browse/MATH-1339
  https://issues.apache.org/jira/browse/MATH-1158
  https://issues.apache.org/jira/browse/MATH-1338

[I've just seen that for branch "feature-MATH-1158" which is
"git rebase"d on "feature-MATH-1335", the push is recreating
all the MATH-1335 commits (as guessed from the flood of emails).
Something I was not expecting: sorry I misunderstood how this
is supposed to work...]


Regards,
Gilles

[1] See the "links" in the relevant JIRA reports.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] RNG refactoring

Evan Ward
I'm not sure if this is the problem, but a good rule of thumb is that if
you have pushed a commit you should merge it instead of rebasing it. It
looks to me like 6ddf476 and ce8c82f are the same, so I think when you
ran rebase it put it on top of the bug fix I pushed up recently,
duplicating the commit.

Best Regards,
Evan

On 03/25/2016 11:34 AM, Gilles wrote:

> Hi.
>
> Last week, and just now, I've pushed local branches that handle
> the following issues (and others, either related, or set to
> "Won't fix [in current code]" in JIRA[1]):
>
>  https://issues.apache.org/jira/browse/MATH-1335
>  https://issues.apache.org/jira/browse/MATH-1336
>  https://issues.apache.org/jira/browse/MATH-1337
>  https://issues.apache.org/jira/browse/MATH-1339
>  https://issues.apache.org/jira/browse/MATH-1158
>  https://issues.apache.org/jira/browse/MATH-1338
>
> [I've just seen that for branch "feature-MATH-1158" which is
> "git rebase"d on "feature-MATH-1335", the push is recreating
> all the MATH-1335 commits (as guessed from the flood of emails).
> Something I was not expecting: sorry I misunderstood how this
> is supposed to work...]
>
>
> Regards,
> Gilles
>
> [1] See the "links" in the relevant JIRA reports.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Math] "rebase" vs "merge" (Was: RNG refactoring)

Gilles Sadowski
On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> I'm not sure if this is the problem, but a good rule of thumb is that
> if
> you have pushed a commit

Did I?

What I wanted is
  * publish code ("feature-MATH-1335")
  * publish code ("feature-MATH-1158") that requires the new code
    present in "feature-MATH-1335"

So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
to incorporate everything from there. [What "git" tells during this
operation looks like the right thing to do.]

By the way, I did the same with your change: I "rebase"d all my local
branches on "develop" after your merged your change to that branch.

What is the difference with "merge" and if "merge" should have been
used, then when does one use "rebase"?

Maybe I did the right thing; and it's just normal that there is an
email flood in such cases...

Thanks,
Gilles

> you should merge it instead of rebasing it. It
> looks to me like 6ddf476 and ce8c82f are the same, so I think when
> you
> ran rebase it put it on top of the bug fix I pushed up recently,
> duplicating the commit.
>
> Best Regards,
> Evan
>
> On 03/25/2016 11:34 AM, Gilles wrote:
>> Hi.
>>
>> Last week, and just now, I've pushed local branches that handle
>> the following issues (and others, either related, or set to
>> "Won't fix [in current code]" in JIRA[1]):
>>
>>  https://issues.apache.org/jira/browse/MATH-1335
>>  https://issues.apache.org/jira/browse/MATH-1336
>>  https://issues.apache.org/jira/browse/MATH-1337
>>  https://issues.apache.org/jira/browse/MATH-1339
>>  https://issues.apache.org/jira/browse/MATH-1158
>>  https://issues.apache.org/jira/browse/MATH-1338
>>
>> [I've just seen that for branch "feature-MATH-1158" which is
>> "git rebase"d on "feature-MATH-1335", the push is recreating
>> all the MATH-1335 commits (as guessed from the flood of emails).
>> Something I was not expecting: sorry I misunderstood how this
>> is supposed to work...]
>>
>>
>> Regards,
>> Gilles
>>
>> [1] See the "links" in the relevant JIRA reports.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)

Al Chou-2
Unlike a regular merge, rebase applies a branch's commits' changes onto the specified commit (which is typically identified by specifying a branch name), in the same order as they appear in the branch that is being rebased. The name of the command says that you are redefining the "base", in other words, the starting point, of the branch. Depending on the changes made by those commits, you may see what appears to be the same commit/change applied more than once. See http://ProGit.org/book for great explanations of this and other Git features.

Al

On Mar 26, 2016, 12:01 -0700, Gilles<[hidden email]>, wrote:

> On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> > I'm not sure if this is the problem, but a good rule of thumb is that
> > if
> > you have pushed a commit
>
> Did I?
>
> What I wanted is
> * publish code ("feature-MATH-1335")
> * publish code ("feature-MATH-1158") that requires the new code
> present in "feature-MATH-1335"
>
> So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
> to incorporate everything from there. [What "git" tells during this
> operation looks like the right thing to do.]
>
> By the way, I did the same with your change: I "rebase"d all my local
> branches on "develop" after your merged your change to that branch.
>
> What is the difference with "merge" and if "merge" should have been
> used, then when does one use "rebase"?
>
> Maybe I did the right thing; and it's just normal that there is an
> email flood in such cases...
>
> Thanks,
> Gilles
>
> > you should merge it instead of rebasing it. It
> > looks to me like 6ddf476 and ce8c82f are the same, so I think when
> > you
> > ran rebase it put it on top of the bug fix I pushed up recently,
> > duplicating the commit.
> >
> > Best Regards,
> > Evan
> >
> > On 03/25/2016 11:34 AM, Gilles wrote:
> > > Hi.
> > >
> > > Last week, and just now, I've pushed local branches that handle
> > > the following issues (and others, either related, or set to
> > > "Won't fix [in current code]" in JIRA[1]):
> > >
> > > https://issues.apache.org/jira/browse/MATH-1335
> > > https://issues.apache.org/jira/browse/MATH-1336
> > > https://issues.apache.org/jira/browse/MATH-1337
> > > https://issues.apache.org/jira/browse/MATH-1339
> > > https://issues.apache.org/jira/browse/MATH-1158
> > > https://issues.apache.org/jira/browse/MATH-1338
> > >
> > > [I've just seen that for branch "feature-MATH-1158" which is
> > > "git rebase"d on "feature-MATH-1335", the push is recreating
> > > all the MATH-1335 commits (as guessed from the flood of emails).
> > > Something I was not expecting: sorry I misunderstood how this
> > > is supposed to work...]
> > >
> > >
> > > Regards,
> > > Gilles
> > >
> > > [1] See the "links" in the relevant JIRA reports.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)

Matt Sicker
In general, don't use rebase on branches that other people are also using
without first making sure everyone is willing to also rebase their own
local copies. To do that, they can run "git pull --rebase" to update when
you've force-pushed a rebased branch. This is generally looked down upon,
but is sometimes necessary.

On 26 March 2016 at 17:33, <[hidden email]> wrote:

> Unlike a regular merge, rebase applies a branch's commits' changes onto
> the specified commit (which is typically identified by specifying a branch
> name), in the same order as they appear in the branch that is being
> rebased. The name of the command says that you are redefining the "base",
> in other words, the starting point, of the branch. Depending on the changes
> made by those commits, you may see what appears to be the same
> commit/change applied more than once. See http://ProGit.org/book for
> great explanations of this and other Git features.
>
> Al
>
> On Mar 26, 2016, 12:01 -0700, Gilles<[hidden email]>, wrote:
> > On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> > > I'm not sure if this is the problem, but a good rule of thumb is that
> > > if
> > > you have pushed a commit
> >
> > Did I?
> >
> > What I wanted is
> > * publish code ("feature-MATH-1335")
> > * publish code ("feature-MATH-1158") that requires the new code
> > present in "feature-MATH-1335"
> >
> > So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
> > to incorporate everything from there. [What "git" tells during this
> > operation looks like the right thing to do.]
> >
> > By the way, I did the same with your change: I "rebase"d all my local
> > branches on "develop" after your merged your change to that branch.
> >
> > What is the difference with "merge" and if "merge" should have been
> > used, then when does one use "rebase"?
> >
> > Maybe I did the right thing; and it's just normal that there is an
> > email flood in such cases...
> >
> > Thanks,
> > Gilles
> >
> > > you should merge it instead of rebasing it. It
> > > looks to me like 6ddf476 and ce8c82f are the same, so I think when
> > > you
> > > ran rebase it put it on top of the bug fix I pushed up recently,
> > > duplicating the commit.
> > >
> > > Best Regards,
> > > Evan
> > >
> > > On 03/25/2016 11:34 AM, Gilles wrote:
> > > > Hi.
> > > >
> > > > Last week, and just now, I've pushed local branches that handle
> > > > the following issues (and others, either related, or set to
> > > > "Won't fix [in current code]" in JIRA[1]):
> > > >
> > > > https://issues.apache.org/jira/browse/MATH-1335
> > > > https://issues.apache.org/jira/browse/MATH-1336
> > > > https://issues.apache.org/jira/browse/MATH-1337
> > > > https://issues.apache.org/jira/browse/MATH-1339
> > > > https://issues.apache.org/jira/browse/MATH-1158
> > > > https://issues.apache.org/jira/browse/MATH-1338
> > > >
> > > > [I've just seen that for branch "feature-MATH-1158" which is
> > > > "git rebase"d on "feature-MATH-1335", the push is recreating
> > > > all the MATH-1335 commits (as guessed from the flood of emails).
> > > > Something I was not expecting: sorry I misunderstood how this
> > > > is supposed to work...]
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > [1] See the "links" in the relevant JIRA reports.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)

Al Chou-2
Agreed, changing the commit ancestry history of a branch that other people have already (even merely potentially) fetched and checked out locally is generally frowned upon.  Interesting to hear that anyone ever has gotten consensus to do so via "pull --rebase"!  On rare occasions at my job we have needed to "push --force" a publicly shared branch to clear up a problem, and we do get consensus before doing so, but no one enjoys those situations.
Al

    On Sunday, March 27, 2016 5:44 PM, Matt Sicker <[hidden email]> wrote:
 

 In general, don't use rebase on branches that other people are also using
without first making sure everyone is willing to also rebase their own
local copies. To do that, they can run "git pull --rebase" to update when
you've force-pushed a rebased branch. This is generally looked down upon,
but is sometimes necessary.

On 26 March 2016 at 17:33, <[hidden email]> wrote:

> Unlike a regular merge, rebase applies a branch's commits' changes onto
> the specified commit (which is typically identified by specifying a branch
> name), in the same order as they appear in the branch that is being
> rebased. The name of the command says that you are redefining the "base",
> in other words, the starting point, of the branch. Depending on the changes
> made by those commits, you may see what appears to be the same
> commit/change applied more than once. See http://ProGit.org/book for
> great explanations of this and other Git features.
>
> Al
>
> On Mar 26, 2016, 12:01 -0700, Gilles<[hidden email]>, wrote:
> > On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> > > I'm not sure if this is the problem, but a good rule of thumb is that
> > > if
> > > you have pushed a commit
> >
> > Did I?
> >
> > What I wanted is
> > * publish code ("feature-MATH-1335")
> > * publish code ("feature-MATH-1158") that requires the new code
> > present in "feature-MATH-1335"
> >
> > So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
> > to incorporate everything from there. [What "git" tells during this
> > operation looks like the right thing to do.]
> >
> > By the way, I did the same with your change: I "rebase"d all my local
> > branches on "develop" after your merged your change to that branch.
> >
> > What is the difference with "merge" and if "merge" should have been
> > used, then when does one use "rebase"?
> >
> > Maybe I did the right thing; and it's just normal that there is an
> > email flood in such cases...
> >
> > Thanks,
> > Gilles
> >
> > > you should merge it instead of rebasing it. It
> > > looks to me like 6ddf476 and ce8c82f are the same, so I think when
> > > you
> > > ran rebase it put it on top of the bug fix I pushed up recently,
> > > duplicating the commit.
> > >
> > > Best Regards,
> > > Evan
> > >
> > > On 03/25/2016 11:34 AM, Gilles wrote:
> > > > Hi.
> > > >
> > > > Last week, and just now, I've pushed local branches that handle
> > > > the following issues (and others, either related, or set to
> > > > "Won't fix [in current code]" in JIRA[1]):
> > > >
> > > > https://issues.apache.org/jira/browse/MATH-1335
> > > > https://issues.apache.org/jira/browse/MATH-1336
> > > > https://issues.apache.org/jira/browse/MATH-1337
> > > > https://issues.apache.org/jira/browse/MATH-1339
> > > > https://issues.apache.org/jira/browse/MATH-1158
> > > > https://issues.apache.org/jira/browse/MATH-1338
> > > >
> > > > [I've just seen that for branch "feature-MATH-1158" which is
> > > > "git rebase"d on "feature-MATH-1335", the push is recreating
> > > > all the MATH-1335 commits (as guessed from the flood of emails).
> > > > Something I was not expecting: sorry I misunderstood how this
> > > > is supposed to work...]
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > [1] See the "links" in the relevant JIRA reports.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>



--
Matt Sicker <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)

Matt Sicker
I once had to do a git filter-branch to remove an emoji from a commit
message that broke our CI server because it was using MySQL. That was fun,
plus I had to get all my co-workers to do a git pull --rebase. So yeah,
there are occasional uses for breaking everyone's history.

On 27 March 2016 at 19:49, Al Chou <[hidden email]> wrote:

> Agreed, changing the commit ancestry history of a branch that other people
> have already (even merely potentially) fetched and checked out locally is
> generally frowned upon.  Interesting to hear that anyone ever has gotten
> consensus to do so via "pull --rebase"!  On rare occasions at my job we
> have needed to "push --force" a publicly shared branch to clear up a
> problem, and we do get consensus before doing so, but no one enjoys those
> situations.
> Al
>
>     On Sunday, March 27, 2016 5:44 PM, Matt Sicker <[hidden email]>
> wrote:
>
>
>  In general, don't use rebase on branches that other people are also using
> without first making sure everyone is willing to also rebase their own
> local copies. To do that, they can run "git pull --rebase" to update when
> you've force-pushed a rebased branch. This is generally looked down upon,
> but is sometimes necessary.
>
> On 26 March 2016 at 17:33, <[hidden email]> wrote:
>
> > Unlike a regular merge, rebase applies a branch's commits' changes onto
> > the specified commit (which is typically identified by specifying a
> branch
> > name), in the same order as they appear in the branch that is being
> > rebased. The name of the command says that you are redefining the "base",
> > in other words, the starting point, of the branch. Depending on the
> changes
> > made by those commits, you may see what appears to be the same
> > commit/change applied more than once. See http://ProGit.org/book for
> > great explanations of this and other Git features.
> >
> > Al
> >
> > On Mar 26, 2016, 12:01 -0700, Gilles<[hidden email]>,
> wrote:
> > > On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> > > > I'm not sure if this is the problem, but a good rule of thumb is that
> > > > if
> > > > you have pushed a commit
> > >
> > > Did I?
> > >
> > > What I wanted is
> > > * publish code ("feature-MATH-1335")
> > > * publish code ("feature-MATH-1158") that requires the new code
> > > present in "feature-MATH-1335"
> > >
> > > So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
> > > to incorporate everything from there. [What "git" tells during this
> > > operation looks like the right thing to do.]
> > >
> > > By the way, I did the same with your change: I "rebase"d all my local
> > > branches on "develop" after your merged your change to that branch.
> > >
> > > What is the difference with "merge" and if "merge" should have been
> > > used, then when does one use "rebase"?
> > >
> > > Maybe I did the right thing; and it's just normal that there is an
> > > email flood in such cases...
> > >
> > > Thanks,
> > > Gilles
> > >
> > > > you should merge it instead of rebasing it. It
> > > > looks to me like 6ddf476 and ce8c82f are the same, so I think when
> > > > you
> > > > ran rebase it put it on top of the bug fix I pushed up recently,
> > > > duplicating the commit.
> > > >
> > > > Best Regards,
> > > > Evan
> > > >
> > > > On 03/25/2016 11:34 AM, Gilles wrote:
> > > > > Hi.
> > > > >
> > > > > Last week, and just now, I've pushed local branches that handle
> > > > > the following issues (and others, either related, or set to
> > > > > "Won't fix [in current code]" in JIRA[1]):
> > > > >
> > > > > https://issues.apache.org/jira/browse/MATH-1335
> > > > > https://issues.apache.org/jira/browse/MATH-1336
> > > > > https://issues.apache.org/jira/browse/MATH-1337
> > > > > https://issues.apache.org/jira/browse/MATH-1339
> > > > > https://issues.apache.org/jira/browse/MATH-1158
> > > > > https://issues.apache.org/jira/browse/MATH-1338
> > > > >
> > > > > [I've just seen that for branch "feature-MATH-1158" which is
> > > > > "git rebase"d on "feature-MATH-1335", the push is recreating
> > > > > all the MATH-1335 commits (as guessed from the flood of emails).
> > > > > Something I was not expecting: sorry I misunderstood how this
> > > > > is supposed to work...]
> > > > >
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > > [1] See the "links" in the relevant JIRA reports.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
>
>
>
> --
> Matt Sicker <[hidden email]>
>
>
>
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

[Math] Upgrade of CM codes that use RNG (deprecation)

Gilles Sadowski
In reply to this post by Gilles Sadowski
Hello.

In line with several requests for comments on the refactoring
and extensions of the Commons Math (CM) RNG functionalities:
   http://markmail.org/message/vbe3fctp5wvfueos
   http://markmail.org/message/cgungakhneiksdex
   http://markmail.org/message/p3mnx5qnfwjknme2
I intend, in the coming weeks, to
  * replace all CM internal calls to the old API with calls to
    the new API,
  * delete the classes that will have become obsolete (i.e. not
    used anymore within CM, and whose functionality has been
    duplicated).

Anyone can easily test the new API by downloading the following
snapshot of the code currently in the "develop" branch":
 
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-math4/4.0-SNAPSHOT/commons-math4-4.0-20160422.002002-573.jar

Any issue, please post to the "dev" ML,[1]
   <[hidden email]>
or on the bug-tracking system
   https://issues.apache.org/jira/browse/MATH/

Regards,
Gilles

[1] Subscription is required:
       http://commons.apache.org/proper/commons-math/mail-lists.html


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]