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@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
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
