[Rd] Why R should never move to git

Duncan Murdoch
Thu, 25 Jan 2018 11:20:09 -0000

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