[Rd] Why R should never move to git

Iñaki Úcar
Thu, 25 Jan 2018 07:57:48 -0000

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?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



--
I?aki ?car
http://www.enchufa2.es
@Enchufa2