From edd at debian.org  Thu Jan 25 12:49:09 2018
From: edd at debian.org (Dirk Eddelbuettel)
Date: Thu, 25 Jan 2018 05:49:09 -0600
Subject: [Rd] Why R should never move to git
In-Reply-To: <cd23e17b-776f-ffb9-010b-e8b649e3d834@gmail.com>
References: <10a2b81e-4d5d-e387-5e0d-bfe58fbf16ca@gmail.com>
 <CALEXWq0cwhKzuPhPu+ZRChBA0dQLT=s6HobPPDSFb7T9uEhD0w@mail.gmail.com>
 <cd23e17b-776f-ffb9-010b-e8b649e3d834@gmail.com>
Message-ID: <23145.50229.740754.555607@bud.eddelbuettel.com>


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



[Rd] Why R should never move to git
Dirk Eddelbuettel