From murdoch.duncan at gmail.com  Thu Jan 25 01:24:38 2018
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Wed, 24 Jan 2018 19:24:38 -0500
Subject: [Rd] Why R should never move to git
In-Reply-To: <CABtg=KkzmuqeGmi2JUa5fOJXrY_9=J2Z7Uh3s68Y99GQACgUBw@mail.gmail.com>
References: <10a2b81e-4d5d-e387-5e0d-bfe58fbf16ca@gmail.com>
 <CABtg=K=apVWjEaE6pcv0FBkOMDJHFeBLPi9VU3n_+xmuYs4gVg@mail.gmail.com>
 <ba18a519-73c0-5b00-ae47-5b7e411e1600@gmail.com>
 <CABtg=KkzmuqeGmi2JUa5fOJXrY_9=J2Z7Uh3s68Y99GQACgUBw@mail.gmail.com>
Message-ID: <e2b65210-ef35-9975-0aef-648ab81f289b@gmail.com>

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
> <murdoch.duncan at gmail.com> 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
>>> <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