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 > > >
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)
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
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
2018-01-25 12:20 GMT+01:00 Duncan Murdoch <murdoch.duncan at gmail.com>:> 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.)Sorry for the confusion: the step of renaming your master branch isn't really needed, because you can pull the original master branch and call it whatever you want in one command. The process is as follows: 1) Add the upstream repo as another remote: git remote add upstream https://github.com/the/original/repo 2) Pull the upstream master with a different name: git pull upstream master:patch2 3) Edit, add, commit and push patch2 to your fork: git checkout patch2 ... git push origin patch2 4) open a fresh new PR from "patch2" (the first one is intact). I?aki> > Duncan Murdoch >
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 >
On 25/01/2018 7:03 AM, I?aki ?car wrote:> 2018-01-25 12:20 GMT+01:00 Duncan Murdoch <murdoch.duncan at gmail.com>: >> 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.) > > Sorry for the confusion: the step of renaming your master branch isn't > really needed, because you can pull the original master branch and > call it whatever you want in one command. The process is as follows:Thanks. I've tried some of this, and am a little confused.> > 1) Add the upstream repo as another remote: > > git remote add upstream https://github.com/the/original/repo > > 2) Pull the upstream master with a different name: > > git pull upstream master:patch2I've done all that, and now on my local copy I have a branch. I called it "upstreamMaster", because at this point it matches the upstream master, and I intend to maintain it that way.> > 3) Edit, add, commit and push patch2 to your fork: > > git checkout patch2 > ... > git push origin patch2I did this, except that the "..." contains nothing, because I want this branch to continue. But now my problem is that I can't see any way to tell Github about this new branch. I ran git push origin upstreamMaster and got Total 0 (delta 0), reused 0 (delta 0) To https://github.com/dmurdoch/manipulateWidget * [new branch] upstreamMaster -> upstreamMaster but that branch doesn't show up in the Github web site. Any suggestions? Duncan Murdoch> > 4) open a fresh new PR from "patch2" (the first one is intact).