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@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
This email message may contain legally privileged and/or...{{dropped:2}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
