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 at rob:~$ cd git/rcpp > edd at rob:~/git/rcpp(master)$ git checkout -b feature/new_branch_to_show > Switched to a new branch 'feature/new_branch_to_show' > edd at rob:~/git/rcpp(feature/new_branch_to_show)$ git checkout - > Switched to branch 'master' > Your branch is up-to-date with 'origin/master'. > edd at rob:~/git/rcpp(master)$ git branch -d feature/new_branch_to_show > Deleted branch feature/new_branch_to_show (was 5b25fe62). > edd at 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.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 > | > > | > > | > > | > | ______________________________________________ > | R-devel at r-project.org mailing list > | https://stat.ethz.ch/mailman/listinfo/r-devel >
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 at rob:~$ cd git/rcpp
>> ???? edd at rob:~/git/rcpp(master)$ git checkout -b
feature/new_branch_to_show
>> ???? Switched to a new branch 'feature/new_branch_to_show'
>> ???? edd at rob:~/git/rcpp(feature/new_branch_to_show)$ git checkout -
>> ???? Switched to branch 'master'
>> ???? Your branch is up-to-date with 'origin/master'.
>> ???? edd at rob:~/git/rcpp(master)$ git branch -d
feature/new_branch_to_show
>> ???? Deleted branch feature/new_branch_to_show (was 5b25fe62).
>> ???? edd at 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.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
>> | >
>> | >
>> | >
>> |
>> | ______________________________________________
>> | R-devel at r-project.org mailing list
>> | https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> R-devel at 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/
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 at rob:~$ cd git/rcpp >>> ???? edd at rob:~/git/rcpp(master)$ git checkout -b feature/new_branch_to_show >>> ???? Switched to a new branch 'feature/new_branch_to_show' >>> ???? edd at rob:~/git/rcpp(feature/new_branch_to_show)$ git checkout - >>> ???? Switched to branch 'master' >>> ???? Your branch is up-to-date with 'origin/master'. >>> ???? edd at rob:~/git/rcpp(master)$ git branch -d feature/new_branch_to_show >>> ???? Deleted branch feature/new_branch_to_show (was 5b25fe62). >>> ???? edd at 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.duncan at 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 at 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 at 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 at 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 at 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
On 01/25/2018 07:09 AM, 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.A different starting point gives R-core members write access to the R-core git, which is analogous to the current svn setup. A restricted set of commands are needed, mimicking svn git clone ... # svn co git pull # svn up [...; git commit ...] git push ... # svn ci Probably this would mature quickly into a better practice where new features / bug fixes are developed on a local branch. A subset of R-core might participate in managing pull requests on a 'read only' Github mirror. Incorporating mature patches would involve git, rather than the Github GUI. In one's local repository, create a new branch and pull from the repository making the request git checkout -b a-pull-request master git pull https://github.com/a-user/their.git their-branch Check and modify, then merge locally and push to the R-core git ## identify standard / best practice for merging branches git checkout master git merge ... a-pull-request git push ... Creating pull requests is a problem for the developer wanting to contribute to R, not for the R-core developer. As we've seen in this thread, R-core would not need to feel responsible for helping developers create pull requests. Martin Morgan> > 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 at rob:~$ cd git/rcpp >> ???? edd at rob:~/git/rcpp(master)$ git checkout -b >> feature/new_branch_to_show >> ???? Switched to a new branch 'feature/new_branch_to_show' >> ???? edd at rob:~/git/rcpp(feature/new_branch_to_show)$ git checkout - >> ???? Switched to branch 'master' >> ???? Your branch is up-to-date with 'origin/master'. >> ???? edd at rob:~/git/rcpp(master)$ git branch -d feature/new_branch_to_show >> ???? Deleted branch feature/new_branch_to_show (was 5b25fe62). >> ???? edd at 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.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 >> | > >> | > >> | > >> | >> | ______________________________________________ >> | R-devel at r-project.org mailing list >> | https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-develThis email message may contain legally privileged and/or...{{dropped:2}}