From murdoch.duncan at gmail.com  Thu Jan 25 00:56:41 2018
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Wed, 24 Jan 2018 18:56:41 -0500
Subject: [Rd] Why R should never move to git
In-Reply-To: <CABtg=K=apVWjEaE6pcv0FBkOMDJHFeBLPi9VU3n_+xmuYs4gVg@mail.gmail.com>
References: <10a2b81e-4d5d-e387-5e0d-bfe58fbf16ca@gmail.com>
 <CABtg=K=apVWjEaE6pcv0FBkOMDJHFeBLPi9VU3n_+xmuYs4gVg@mail.gmail.com>
Message-ID: <ba18a519-73c0-5b00-ae47-5b7e411e1600@gmail.com>

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
> <murdoch.duncan at gmail.com> 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
>> <https://github.com/dmurdoch/manipulateWidget>.
>>
>> - I checked out my fork into RStudio.
>>
>> - I fixed the bug, and submitted the pull request
>> <https://github.com/rte-antares-rpackage/manipulateWidget/pull/47>.
>>
>> 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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] Why R should never move to git
Duncan Murdoch