[Rd] fix potential integer overflow in mantelhaen.test ?

[Ben Bolker]

  Someone who was running into an integer overflow warning (and
downstream error) with mantelhaen.test() on a large data set asked about
it on StackOverflow:

https://stackoverflow.com/questions/48422398/na-nan-inf-in-foreign-function-error-with-mantelhaen-test/48428596#48428596

  Coercing ntot to double (i.e. ntot -> as.numeric(ntot)) on lines 283
and 285 here:

https://github.com/wch/r-source/blob/af7f52f70101960861e5d995d3a4bec010bc89e6/src/library/stats/R/mantelhaen.test.R#L283

  seems to fix the problem, fairly harmlessly (*maybe* there are some
edge cases where the integer and floating-point computations give
different answers??? these values are going to get sent to qr.solve() a
few lines later in any case ...)

   If people think this is worthwhile I could submit a bug report.

 cheers
   Ben Bolker

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R-3.4.3 frequently segfaults on HP-UX 11.31

[Dmitry Zotikov]

I've built R-3.4.3 on HP-UX 11.31 with GCC-4.9.2.  However, it segfaults
frequently, and I can't clearly understand why.

Some things work, like

> 1+2
[1] 3
> sum(c(1,2))
[1] 3
> var(c(1,2,3))
[1] 1

Some don't:

> pgamma(1,Inf,Inf)
*** caught segfault ***
address d065, cause 'invalid permissions'

Traceback:
1: pgamma(1, Inf, Inf)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
R is aborting now ...
Segmentation fault (core dumped)

The 'cause' may be very different.

GCC's C and C++ compilers were already installed in the system, but I built
gfortran myself.  It didn't work from first time, so I had to experiment with
optimization flags and some other configure keys.  Although compiled through
the proper 3-stage boostrap procedure, I have no certainty that gfortran is
absolutely flawless, and if possible, I'd like to rule it out first.

Here's output from file and ldd (some libs are installed locally to, say,
$LOCAL):

$ file bin/exec/R
bin/exec/R: ELF-32 executable object file - IA64

$ ldd bin/exec/R

bin/exec/R:
    /usr/lib/hpux32/libpthread.so =>    /usr/lib/hpux32/libpthread.so
    libRblas.sl =>  $LOCAL/var/build/R-3.4.3/lib/libRblas.sl
    libgfortran.so.3 => $LOCAL/lib/libgfortran.so.3
    libm.so.1 =>    /usr/lib/hpux32/libm.so.1
    libunwind.so.1 =>   /usr/lib/hpux32/libunwind.so.1
    libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1
    /usr/local/lib/hpux32/libintl.so => /usr/local/lib/hpux32/libintl.so
    /usr/local/lib/hpux32/libiconv.so =>    
/usr/local/lib/hpux32/libiconv.so
    libpcre.so.3 => $LOCAL/lib/libpcre.so.3
    liblzma.so =>   /usr/local/lib/hpux32/liblzma.so
    libbz2.so =>    /usr/local/lib/hpux32/libbz2.so
    libz.so =>  /usr/local/lib/hpux32/libz.so
    libnsl.so.1 =>  /usr/lib/hpux32/libnsl.so.1
    librt.so.1 =>   /usr/lib/hpux32/librt.so.1
    libc.so.1 =>    /usr/lib/hpux32/libc.so.1
    libgfortran.so.3 => $LOCAL/lib/libgfortran.so.3
    libm.so.1 =>    /usr/lib/hpux32/libm.so.1
    libunwind.so.1 =>   /usr/lib/hpux32/libunwind.so.1
    libgcc_s.so.0 =>    $LOCAL/lib/libgcc_s.so.0
    libm.so.1 =>    /usr/lib/hpux32/libm.so.1
    libc.so.1 =>    /usr/lib/hpux32/libc.so.1
    libgcc_s.so.0 =>    $LOCAL/lib/libgcc_s.so.0
    libunwind.so.1 =>   /usr/lib/hpux32/libunwind.so.1
    libuca.so.1 =>  /usr/lib/hpux32/libuca.so.1
    libiconv.so =>  /usr/local/lib/hpux32/libiconv.so
    libc.so.1 =>    /usr/lib/hpux32/libc.so.1
    libc.so.1 =>    /usr/lib/hpux32/libc.so.1
    libpthread.so.1 =>  /usr/lib/hpux32/libpthread.so.1
    libc.so.1 =>    /usr/lib/hpux32/libc.so.1
    libc.so.1 =>    /usr/lib/hpux32/libc.so.1
    libxti.so.1 =>  /usr/lib/hpux32/libxti.so.1
    libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1
    libc.so.1 =>    /usr/lib/hpux32/libc.so.1
    libunwind.so.1 =>   /usr/lib/hpux32/libunwind.so.1

Where should I go looking first?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Why R should never move to git

[Duncan Murdoch]

Lately I've been doing some work with the manipulateWidget package, 
which lives on Github at 
https://github.com/rte-antares-rpackage/manipulateWidget/.  Last week I 
found a bug, so being a good community member, I put together a patch.


Since the package lives on Github, I followed instructions to put 
together a "pull request":


- I forked the main branch to my own Github account as 
.


- I checked out my fork into RStudio.

- I fixed the bug, and submitted the pull request 
.


Then I felt good about myself, and continued on with my work.  Today I 
tracked down another bug, unrelated to the previous one.  I know enough 
about git to know that I shouldn't commit this fix to my fork, because 
it would then become part of the previous pull request.


So I created a branch within my fork, and committed the change there. 
But Github provides no way to create a pull request that only includes 
the new stuff!  Every attempt I made would have included everything from 
both bug fixes.


I've read online about creating a new branch based on the master copy, 
and "cherry picking" just the final change:  but all the instructions 
I've tried so far have failed.


Okay, I know the solution:  I need to burn the whole thing down (to 
quote Jenny Bryan).  I'll just create a new fork, and put the new bug 
fix in a branch there.


I can't!  I don't know if this is a Git restriction or a Github 
restriction, but it won't let me create a new fork without deleting the 
old one.  I don't know if deleting the previous fork would also delete 
the previous PR, so I'm not going to do this.


This is ridiculous!  It is such an easy concept:  I want to take the 
diff between my most recent commit and the one before, and send that 
diff to the owners of the master copy.  This should be a trivial (and it 
is in svn).


Git and Github allow the most baroque arrangements, but can't do this 
simple task.  That's an example of really bad UI design.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Gábor Csárdi]

When you create a branch for your bug fix, don't create it off the
previous fix. Create it off the original, forked state of the repo.

Are the two commits here your fixes?
https://github.com/dmurdoch/manipulateWidget/commits/master

Gabor

On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch
 wrote:
> Lately I've been doing some work with the manipulateWidget package, which
> lives on Github at
> https://github.com/rte-antares-rpackage/manipulateWidget/.  Last week I
> found a bug, so being a good community member, I put together a patch.
>
> Since the package lives on Github, I followed instructions to put together a
> "pull request":
>
> - I forked the main branch to my own Github account as
> .
>
> - I checked out my fork into RStudio.
>
> - I fixed the bug, and submitted the pull request
> .
>
> Then I felt good about myself, and continued on with my work.  Today I
> tracked down another bug, unrelated to the previous one.  I know enough
> about git to know that I shouldn't commit this fix to my fork, because it
> would then become part of the previous pull request.
>
> So I created a branch within my fork, and committed the change there. But
> Github provides no way to create a pull request that only includes the new
> stuff!  Every attempt I made would have included everything from both bug
> fixes.
>
> I've read online about creating a new branch based on the master copy, and
> "cherry picking" just the final change:  but all the instructions I've tried
> so far have failed.
>
> Okay, I know the solution:  I need to burn the whole thing down (to quote
> Jenny Bryan).  I'll just create a new fork, and put the new bug fix in a
> branch there.
>
> I can't!  I don't know if this is a Git restriction or a Github restriction,
> but it won't let me create a new fork without deleting the old one.  I don't
> know if deleting the previous fork would also delete the previous PR, so I'm
> not going to do this.
>
> This is ridiculous!  It is such an easy concept:  I want to take the diff
> between my most recent commit and the one before, and send that diff to the
> owners of the master copy.  This should be a trivial (and it is in svn).
>
> Git and Github allow the most baroque arrangements, but can't do this simple
> task.  That's an example of really bad UI design.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Hugh Parsonage]

I think the problem you're experiencing is not uncommon but has a solution.

FWIW, I prefer git, but I think the best version control system for R
is whatever R-core prefers. If they were 2% more productive working in
an MS Word documents with Track Changes than git, so much worse for
git.

On 25 January 2018 at 10:17, Duncan Murdoch  wrote:
> Lately I've been doing some work with the manipulateWidget package, which
> lives on Github at
> https://github.com/rte-antares-rpackage/manipulateWidget/.  Last week I
> found a bug, so being a good community member, I put together a patch.
>
> Since the package lives on Github, I followed instructions to put together a
> "pull request":
>
> - I forked the main branch to my own Github account as
> .
>
> - I checked out my fork into RStudio.
>
> - I fixed the bug, and submitted the pull request
> .
>
> Then I felt good about myself, and continued on with my work.  Today I
> tracked down another bug, unrelated to the previous one.  I know enough
> about git to know that I shouldn't commit this fix to my fork, because it
> would then become part of the previous pull request.
>
> So I created a branch within my fork, and committed the change there. But
> Github provides no way to create a pull request that only includes the new
> stuff!  Every attempt I made would have included everything from both bug
> fixes.
>
> I've read online about creating a new branch based on the master copy, and
> "cherry picking" just the final change:  but all the instructions I've tried
> so far have failed.
>
> Okay, I know the solution:  I need to burn the whole thing down (to quote
> Jenny Bryan).  I'll just create a new fork, and put the new bug fix in a
> branch there.
>
> I can't!  I don't know if this is a Git restriction or a Github restriction,
> but it won't let me create a new fork without deleting the old one.  I don't
> know if deleting the previous fork would also delete the previous PR, so I'm
> not going to do this.
>
> This is ridiculous!  It is such an easy concept:  I want to take the diff
> between my most recent commit and the one before, and send that diff to the
> owners of the master copy.  This should be a trivial (and it is in svn).
>
> Git and Github allow the most baroque arrangements, but can't do this simple
> task.  That's an example of really bad UI design.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

On 24/01/2018 6:35 PM, Gábor Csárdi wrote:

When you create a branch for your bug fix, don't create it off the
previous fix. Create it off the original, forked state of the repo.


Branches keepclass2 through to keepclass5 are my attempts to do that. 
As far as I can see they are all the same as keepclass, which was 
branched from the head of the master branch of my fork.


Are the two commits here your fixes?
https://github.com/dmurdoch/manipulateWidget/commits/master


Those are both part of the first PR.  There's a third commit in 
keepclass (and the other branches too...)


If you or someone else tells me the magic commands I need to do what I 
want, I'll appreciate it.  But the main point of my post is that this is 
something that should be easy.  It shouldn't require expert help.  The 
fact that it does is a flaw in the design of Git or Github or both.


Duncan Murdoch



Gabor

On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch
 wrote:

Lately I've been doing some work with the manipulateWidget package, which
lives on Github at
https://github.com/rte-antares-rpackage/manipulateWidget/.  Last week I
found a bug, so being a good community member, I put together a patch.

Since the package lives on Github, I followed instructions to put together a
"pull request":

- I forked the main branch to my own Github account as
.

- I checked out my fork into RStudio.

- I fixed the bug, and submitted the pull request
.

Then I felt good about myself, and continued on with my work.  Today I
tracked down another bug, unrelated to the previous one.  I know enough
about git to know that I shouldn't commit this fix to my fork, because it
would then become part of the previous pull request.

So I created a branch within my fork, and committed the change there. But
Github provides no way to create a pull request that only includes the new
stuff!  Every attempt I made would have included everything from both bug
fixes.

I've read online about creating a new branch based on the master copy, and
"cherry picking" just the final change:  but all the instructions I've tried
so far have failed.

Okay, I know the solution:  I need to burn the whole thing down (to quote
Jenny Bryan).  I'll just create a new fork, and put the new bug fix in a
branch there.

I can't!  I don't know if this is a Git restriction or a Github restriction,
but it won't let me create a new fork without deleting the old one.  I don't
know if deleting the previous fork would also delete the previous PR, so I'm
not going to do this.

This is ridiculous!  It is such an easy concept:  I want to take the diff
between my most recent commit and the one before, and send that diff to the
owners of the master copy.  This should be a trivial (and it is in svn).

Git and Github allow the most baroque arrangements, but can't do this simple
task.  That's an example of really bad UI design.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Gábor Csárdi]

You need to create a branch from the original master, if you do
git log master
then you'll see which commit that is: f735449d679686867e7d3ab70810b09e8cea6366

So create that branch off that and switch to the new branch:
git branch keepclassx f735449d679686867e7d3ab70810b09e8cea6366
git checkout keepclassx

Then do
git log keepclass
to see the id of the new commit that you want to put on top of the new
branch: 0307ccfaa799c5257258eda89f2526347099f0d0
and cherry-pick that:
git cherry-pick 0307ccfaa799c5257258eda89f2526347099f0d0

Now you have a branch that only has the single desired commit, on top
of the original master.

You can now push you new branch to GitHub:
git push --set-upstream origin keepclassx
and then create a new pull request from this branch.

G.

On Wed, Jan 24, 2018 at 11:56 PM, Duncan Murdoch
 wrote:
> On 24/01/2018 6:35 PM, Gábor Csárdi wrote:
>>
>> When you create a branch for your bug fix, don't create it off the
>> previous fix. Create it off the original, forked state of the repo.
>
>
> Branches keepclass2 through to keepclass5 are my attempts to do that. As far
> as I can see they are all the same as keepclass, which was branched from the
> head of the master branch of my fork.
>>
>>
>> Are the two commits here your fixes?
>> https://github.com/dmurdoch/manipulateWidget/commits/master
>
>
> Those are both part of the first PR.  There's a third commit in keepclass
> (and the other branches too...)
>
> If you or someone else tells me the magic commands I need to do what I want,
> I'll appreciate it.  But the main point of my post is that this is something
> that should be easy.  It shouldn't require expert help.  The fact that it
> does is a flaw in the design of Git or Github or both.
>
> Duncan Murdoch
>
>
>>
>> Gabor
>>
>> On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch
>>  wrote:
>>>
>>> Lately I've been doing some work with the manipulateWidget package, which
>>> lives on Github at
>>> https://github.com/rte-antares-rpackage/manipulateWidget/.  Last week I
>>> found a bug, so being a good community member, I put together a patch.
>>>
>>> Since the package lives on Github, I followed instructions to put
>>> together a
>>> "pull request":
>>>
>>> - I forked the main branch to my own Github account as
>>> .
>>>
>>> - I checked out my fork into RStudio.
>>>
>>> - I fixed the bug, and submitted the pull request
>>> .
>>>
>>> Then I felt good about myself, and continued on with my work.  Today I
>>> tracked down another bug, unrelated to the previous one.  I know enough
>>> about git to know that I shouldn't commit this fix to my fork, because it
>>> would then become part of the previous pull request.
>>>
>>> So I created a branch within my fork, and committed the change there. But
>>> Github provides no way to create a pull request that only includes the
>>> new
>>> stuff!  Every attempt I made would have included everything from both bug
>>> fixes.
>>>
>>> I've read online about creating a new branch based on the master copy,
>>> and
>>> "cherry picking" just the final change:  but all the instructions I've
>>> tried
>>> so far have failed.
>>>
>>> Okay, I know the solution:  I need to burn the whole thing down (to quote
>>> Jenny Bryan).  I'll just create a new fork, and put the new bug fix in a
>>> branch there.
>>>
>>> I can't!  I don't know if this is a Git restriction or a Github
>>> restriction,
>>> but it won't let me create a new fork without deleting the old one.  I
>>> don't
>>> know if deleting the previous fork would also delete the previous PR, so
>>> I'm
>>> not going to do this.
>>>
>>> This is ridiculous!  It is such an easy concept:  I want to take the diff
>>> between my most recent commit and the one before, and send that diff to
>>> the
>>> owners of the master copy.  This should be a trivial (and it is in svn).
>>>
>>> Git and Github allow the most baroque arrangements, but can't do this
>>> simple
>>> task.  That's an example of really bad UI design.
>>>
>>> Duncan Murdoch
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

On 24/01/2018 7:04 PM, Gábor Csárdi wrote:

You need to create a branch from the original master, if you do
git log master
then you'll see which commit that is: f735449d679686867e7d3ab70810b09e8cea6366

So create that branch off that and switch to the new branch:
git branch keepclassx f735449d679686867e7d3ab70810b09e8cea6366
git checkout keepclassx

Then do
git log keepclass
to see the id of the new commit that you want to put on top of the new
branch: 0307ccfaa799c5257258eda89f2526347099f0d0
and cherry-pick that:
git cherry-pick 0307ccfaa799c5257258eda89f2526347099f0d0

Now you have a branch that only has the single desired commit, on top
of the original master.

You can now push you new branch to GitHub:
git push --set-upstream origin keepclassx
and then create a new pull request from this branch.


Thanks, those instructions appear to have worked.

For comparison purposes, the equivalent steps in svn would be

svn diff -r PREV:HEAD --internal-diff > patchfile

and then the patchfile could be sent to the maintainer.

Duncan Murdoch



G.

On Wed, Jan 24, 2018 at 11:56 PM, Duncan Murdoch
 wrote:

On 24/01/2018 6:35 PM, Gábor Csárdi wrote:


When you create a branch for your bug fix, don't create it off the
previous fix. Create it off the original, forked state of the repo.



Branches keepclass2 through to keepclass5 are my attempts to do that. As far
as I can see they are all the same as keepclass, which was branched from the
head of the master branch of my fork.



Are the two commits here your fixes?
https://github.com/dmurdoch/manipulateWidget/commits/master



Those are both part of the first PR.  There's a third commit in keepclass
(and the other branches too...)

If you or someone else tells me the magic commands I need to do what I want,
I'll appreciate it.  But the main point of my post is that this is something
that should be easy.  It shouldn't require expert help.  The fact that it
does is a flaw in the design of Git or Github or both.

Duncan Murdoch




Gabor

On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch
 wrote:


Lately I've been doing some work with the manipulateWidget package, which
lives on Github at
https://github.com/rte-antares-rpackage/manipulateWidget/.  Last week I
found a bug, so being a good community member, I put together a patch.

Since the package lives on Github, I followed instructions to put
together a
"pull request":

- I forked the main branch to my own Github account as
.

- I checked out my fork into RStudio.

- I fixed the bug, and submitted the pull request
.

Then I felt good about myself, and continued on with my work.  Today I
tracked down another bug, unrelated to the previous one.  I know enough
about git to know that I shouldn't commit this fix to my fork, because it
would then become part of the previous pull request.

So I created a branch within my fork, and committed the change there. But
Github provides no way to create a pull request that only includes the
new
stuff!  Every attempt I made would have included everything from both bug
fixes.

I've read online about creating a new branch based on the master copy,
and
"cherry picking" just the final change:  but all the instructions I've
tried
so far have failed.

Okay, I know the solution:  I need to burn the whole thing down (to quote
Jenny Bryan).  I'll just create a new fork, and put the new bug fix in a
branch there.

I can't!  I don't know if this is a Git restriction or a Github
restriction,
but it won't let me create a new fork without deleting the old one.  I
don't
know if deleting the previous fork would also delete the previous PR, so
I'm
not going to do this.

This is ridiculous!  It is such an easy concept:  I want to take the diff
between my most recent commit and the one before, and send that diff to
the
owners of the master copy.  This should be a trivial (and it is in svn).

Git and Github allow the most baroque arrangements, but can't do this
simple
task.  That's an example of really bad UI design.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel





__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Gábor Csárdi]

On Thu, Jan 25, 2018 at 12:24 AM, Duncan Murdoch
 wrote:
[...]
> Thanks, those instructions appear to have worked.
>
> For comparison purposes, the equivalent steps in svn would be
>
> svn diff -r PREV:HEAD --internal-diff > patchfile
>
> and then the patchfile could be sent to the maintainer.

If you just want the diff corresponding to the last commit,

git show

will print it for you. Or

git show keepclass

for a specific branch.

G.

[...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

On 24/01/2018 7:29 PM, Gábor Csárdi wrote:

On Thu, Jan 25, 2018 at 12:24 AM, Duncan Murdoch
 wrote:
[...]

Thanks, those instructions appear to have worked.

For comparison purposes, the equivalent steps in svn would be

svn diff -r PREV:HEAD --internal-diff > patchfile

and then the patchfile could be sent to the maintainer.


If you just want the diff corresponding to the last commit,

git show

will print it for you. Or

git show keepclass

for a specific branch.


But that's only half the battle.  If I did that and emailed the diff to 
a maintainer, I'm guessing I'd be told I should put together a PR 
instead.  And as I found out, that's not easy, if I already have a fork 
of the repository that contains changes and I don't want to blow it away.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Gábor Csárdi]

On Thu, Jan 25, 2018 at 12:43 AM, Duncan Murdoch
 wrote:
[...]
> But that's only half the battle.  If I did that and emailed the diff to a
> maintainer, I'm guessing I'd be told I should put together a PR instead.
> And as I found out, that's not easy, if I already have a fork of the
> repository that contains changes and I don't want to blow it away.

You can always create a branch, off any commit in the DAG, as in the
previous emails,
and then replay the changes there.

But there are alternatives as well, e.g. you can also create a branch
from the tip of master,
and then remove the two old commits, and keep the last one. I usually
do this via sg like

git rebase HEAD --interactive

which will start an editor with the 4 latest commits. Then you just
remove the ones
you don't want, save, exit, and then git will perform the rebase, as desired.

G.

> Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Iñaki Úcar]

For what it's worth, this is my workflow:

1. Get a fork.
2. From the master branch, create a new branch called fix-[something].
3. Put together the stuff there, commit, push and open a PR.
4. Checkout master and repeat from 2 to submit another patch.

Sometimes, I forget the step of creating the new branch and I put my
fix on top of the master branch, which complicates things a bit. But
you can always rename your fork's master and pull it again from
upstream.

Iñaki



2018-01-25 0:17 GMT+01:00 Duncan Murdoch :
> Lately I've been doing some work with the manipulateWidget package, which
> lives on Github at
> https://github.com/rte-antares-rpackage/manipulateWidget/.  Last week I
> found a bug, so being a good community member, I put together a patch.
>
> Since the package lives on Github, I followed instructions to put together a
> "pull request":
>
> - I forked the main branch to my own Github account as
> .
>
> - I checked out my fork into RStudio.
>
> - I fixed the bug, and submitted the pull request
> .
>
> Then I felt good about myself, and continued on with my work.  Today I
> tracked down another bug, unrelated to the previous one.  I know enough
> about git to know that I shouldn't commit this fix to my fork, because it
> would then become part of the previous pull request.
>
> So I created a branch within my fork, and committed the change there. But
> Github provides no way to create a pull request that only includes the new
> stuff!  Every attempt I made would have included everything from both bug
> fixes.
>
> I've read online about creating a new branch based on the master copy, and
> "cherry picking" just the final change:  but all the instructions I've tried
> so far have failed.
>
> Okay, I know the solution:  I need to burn the whole thing down (to quote
> Jenny Bryan).  I'll just create a new fork, and put the new bug fix in a
> branch there.
>
> I can't!  I don't know if this is a Git restriction or a Github restriction,
> but it won't let me create a new fork without deleting the old one.  I don't
> know if deleting the previous fork would also delete the previous PR, so I'm
> not going to do this.
>
> This is ridiculous!  It is such an easy concept:  I want to take the diff
> between my most recent commit and the one before, and send that diff to the
> owners of the master copy.  This should be a trivial (and it is in svn).
>
> Git and Github allow the most baroque arrangements, but can't do this simple
> task.  That's an example of really bad UI design.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel