Hi Duncan! I think there are many users whose first experiences with git where frustrating, and trust me, many people here can relate to your pain. I can certainly say that I can. At first, git makes significant effort to become fluent in seemingly "simple" tasks. I can literally feel your pain right now.
But this is the main downside of git: that it can be hard to learn. I overcame this problem by collecting copy-paste-instructions for the most common tasks. I think Dirk provided a very nice starting point for a typical pull request, and next time you need to use git, maybe try his instructions. They are *exactly* what I use at least once a week. However they are not 1:1 for your current situation, where you already started a fork. If you want to solve your current "mess", I personally find the easiest thing to move all local changes away (to /tmp/ or wherever), trash the github fork, and start over with Dirks instructions. At point (4) you can copy your changed files back from /tmp/ and use them for new commits, in this new, clean branch. Everything else should just work. Cheers, Mario On 25.01.2018 13:09, Duncan Murdoch wrote: > On 25/01/2018 6:49 AM, Dirk Eddelbuettel wrote: >> >> On 25 January 2018 at 06:20, Duncan Murdoch wrote: >> | 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.) >> >> 1) Via GUI: fork or clone at github so that you have URL to use in 2) > > Github would not allow me to fork, because I already had a fork of the same > repository. I suppose I could have set up a new user and done it. > > I don't know if cloning the original would have made a difference. I don't > have permission to commit to the original, and the manipulateWidget > maintainers > wouldn't be able to see my private clone, so I don't see how I could create a > PR that they could use. > > Once again, let me repeat: this should be an easy thing to do. So far I'm > pretty convinced that it's actually impossible to do it on the Github website > without hacks like creating a new user. It's not trivial but not that > difficult for a git expert using command line git. > > If R Core chose to switch the R sources to use git and used Github to host a > copy, problems like mine would come up fairly regularly. I don't think R Core > would gain enough from the switch to compensate for the burden of dealing > with these problems. > > Maybe Gitlab or some other front end would be better. > > Duncan Murdoch > >> >> 2) Run >> git clone giturl.... >> to fetch local instance >> 3) Run >> git checkout -b feature/new_thing_a >> (this is 2. above by Inaki) >> 4) Edit, save, compile, test, revise, ... leading to 1 or more commits >> >> 5) Run >> git push origin >> standard configuration should have remote branch follow local branch, I >> think the "long form" is >> git push --set-upstream origin feature/new_thing_a >> >> 6) Run >> git checkout - >> or >> git checkout master >> and you are back in master. Now you can restart at my 3) above for >> branches b, c, d and create independent pull requests >> >> I find it really to have a bash prompt that shows the branch: >> >> edd@rob:~$ cd git/rcpp >> edd@rob:~/git/rcpp(master)$ git checkout -b feature/new_branch_to_show >> Switched to a new branch 'feature/new_branch_to_show' >> edd@rob:~/git/rcpp(feature/new_branch_to_show)$ git checkout - >> Switched to branch 'master' >> Your branch is up-to-date with 'origin/master'. >> edd@rob:~/git/rcpp(master)$ git branch -d feature/new_branch_to_show >> Deleted branch feature/new_branch_to_show (was 5b25fe62). >> edd@rob:~/git/rcpp(master)$ >> >> There are few tutorials out there about how to do it, I once got mine from >> Karthik when we did a Software Carpentry workshop. Happy to detail off-list, >> it adds less than 10 lines to ~/.bashrc. >> >> Dirk >> >> | >> | Duncan Murdoch >> | >> | > Iñaki >> | > >> | > >> | > >> | > 2018-01-25 0:17 GMT+01:00 Duncan Murdoch <murdoch.dun...@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@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 >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 München http://www.biodataanalysis.de/ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel