[Rd] Why R should never move to git
csardi.gabor at gmail.com
Thu Jan 25 01:04:22 CET 2018
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
git log keepclass
to see the id of the new commit that you want to put on top of the new
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.
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?
> 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
>> 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
>>> - 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
>>> stuff! Every attempt I made would have included everything from both bug
>>> I've read online about creating a new branch based on the master copy,
>>> "cherry picking" just the final change: but all the instructions I've
>>> 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
>>> but it won't let me create a new fork without deleting the old one. I
>>> know if deleting the previous fork would also delete the previous PR, so
>>> 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
>>> 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
>>> task. That's an example of really bad UI design.
>>> Duncan Murdoch
>>> R-devel at r-project.org mailing list
More information about the R-devel