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
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 <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
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 <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
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/masterThose 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
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 <murdoch.duncan at gmail.com>:> 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-- I?aki ?car http://www.enchufa2.es @Enchufa2
On 25/01/2018 2:57 AM, I?aki ?car wrote:> 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 saw no way to follow your renaming suggestion. Can you tell me the steps it would take? Remember, there's already a PR from the master branch on my fork. (This is for future reference; I already followed Gabor's more complicated instructions and have solved the immediate problem.) Duncan Murdoch> I?aki > > > > 2018-01-25 0:17 GMT+01:00 Duncan Murdoch <murdoch.duncan at gmail.com>: >> 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 > > >