This is exactly the instruction given in  https://xkcd.com/1597/

cheers, J.O.

On 25/01/18 14:48, Mario Emmenlauer wrote:
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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frte-antares-rpackage%2FmanipulateWidget%2F&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=uJhNCEY4egYlpDCkoGy6mI3WRb5PbkgZiBeCDsurxdg%3D&reserved=0.
  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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdmurdoch%2FmanipulateWidget&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=44irdj5wUdiaOR86LBckjNkHq1QosEZaqIapyXLJw0Q%3D&reserved=0>.
| >>
| >> - I checked out my fork into RStudio.
| >>
| >> - I fixed the bug, and submitted the pull request
| >> 
<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frte-antares-rpackage%2FmanipulateWidget%2Fpull%2F47&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=v2iC1pRbfMGg5lWNYiKbbJ6qILU%2FOwn6V9U4pEJx2cs%3D&reserved=0>.
| >>
| >> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=4SGKvj20hKYiBbbUjsV8tgItxsjAMYmTtJQX0yr8V%2Bs%3D&reserved=0
| >
| >
| >
|
| ______________________________________________
| R-devel@r-project.org mailing list
| 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=4SGKvj20hKYiBbbUjsV8tgItxsjAMYmTtJQX0yr8V%2Bs%3D&reserved=0

______________________________________________
R-devel@r-project.org mailing list
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=4SGKvj20hKYiBbbUjsV8tgItxsjAMYmTtJQX0yr8V%2Bs%3D&reserved=0


Viele Gruesse,

     Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.biodataanalysis.de%2F&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=YcW8DMm%2F%2FSSzWVIiZHwwVZClxz9bl911vECahW2Ynt0%3D&reserved=0

______________________________________________
R-devel@r-project.org mailing list
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=4SGKvj20hKYiBbbUjsV8tgItxsjAMYmTtJQX0yr8V%2Bs%3D&reserved=0

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to