Why R should never move to git

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Why R should never move to git

Duncan Murdoch-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Gábor Csárdi
When you create a branch for your bug fix, don't create it off the
previous fix. Create it off the original, forked state of the repo.

Are the two commits here your fixes?
https://github.com/dmurdoch/manipulateWidget/commits/master

Gabor

On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch
<[hidden email]> wrote:

> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Hugh Parsonage
In reply to this post by Duncan Murdoch-2
I think the problem you're experiencing is not uncommon but has a solution.

FWIW, I prefer git, but I think the best version control system for R
is whatever R-core prefers. If they were 2% more productive working in
an MS Word documents with Track Changes than git, so much worse for
git.

On 25 January 2018 at 10:17, Duncan Murdoch <[hidden email]> wrote:

> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Duncan Murdoch-2
In reply to this post by Gábor Csárdi
On 24/01/2018 6:35 PM, Gábor Csárdi wrote:
> When you create a branch for your bug fix, don't create it off the
> previous fix. Create it off the original, forked state of the repo.

Branches keepclass2 through to keepclass5 are my attempts to do that.
As far as I can see they are all the same as keepclass, which was
branched from the head of the master branch of my fork.
>
> Are the two commits here your fixes?
> https://github.com/dmurdoch/manipulateWidget/commits/master

Those are both part of the first PR.  There's a third commit in
keepclass (and the other branches too...)

If you or someone else tells me the magic commands I need to do what I
want, I'll appreciate it.  But the main point of my post is that this is
something that should be easy.  It shouldn't require expert help.  The
fact that it does is a flaw in the design of Git or Github or both.

Duncan Murdoch

>
> Gabor
>
> On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch
> <[hidden email]> wrote:
>> 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
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Gábor Csárdi
You need to create a branch from the original master, if you do
git log master
then you'll see which commit that is: f735449d679686867e7d3ab70810b09e8cea6366

So create that branch off that and switch to the new branch:
git branch keepclassx f735449d679686867e7d3ab70810b09e8cea6366
git checkout keepclassx

Then do
git log keepclass
to see the id of the new commit that you want to put on top of the new
branch: 0307ccfaa799c5257258eda89f2526347099f0d0
and cherry-pick that:
git cherry-pick 0307ccfaa799c5257258eda89f2526347099f0d0

Now you have a branch that only has the single desired commit, on top
of the original master.

You can now push you new branch to GitHub:
git push --set-upstream origin keepclassx
and then create a new pull request from this branch.

G.

On Wed, Jan 24, 2018 at 11:56 PM, Duncan Murdoch
<[hidden email]> wrote:

> On 24/01/2018 6:35 PM, Gábor Csárdi wrote:
>>
>> When you create a branch for your bug fix, don't create it off the
>> previous fix. Create it off the original, forked state of the repo.
>
>
> Branches keepclass2 through to keepclass5 are my attempts to do that. As far
> as I can see they are all the same as keepclass, which was branched from the
> head of the master branch of my fork.
>>
>>
>> Are the two commits here your fixes?
>> https://github.com/dmurdoch/manipulateWidget/commits/master
>
>
> Those are both part of the first PR.  There's a third commit in keepclass
> (and the other branches too...)
>
> If you or someone else tells me the magic commands I need to do what I want,
> I'll appreciate it.  But the main point of my post is that this is something
> that should be easy.  It shouldn't require expert help.  The fact that it
> does is a flaw in the design of Git or Github or both.
>
> Duncan Murdoch
>
>
>>
>> Gabor
>>
>> On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch
>> <[hidden email]> wrote:
>>>
>>> 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
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Duncan Murdoch-2
On 24/01/2018 7:04 PM, Gábor Csárdi wrote:

> You need to create a branch from the original master, if you do
> git log master
> then you'll see which commit that is: f735449d679686867e7d3ab70810b09e8cea6366
>
> So create that branch off that and switch to the new branch:
> git branch keepclassx f735449d679686867e7d3ab70810b09e8cea6366
> git checkout keepclassx
>
> Then do
> git log keepclass
> to see the id of the new commit that you want to put on top of the new
> branch: 0307ccfaa799c5257258eda89f2526347099f0d0
> and cherry-pick that:
> git cherry-pick 0307ccfaa799c5257258eda89f2526347099f0d0
>
> Now you have a branch that only has the single desired commit, on top
> of the original master.
>
> You can now push you new branch to GitHub:
> git push --set-upstream origin keepclassx
> and then create a new pull request from this branch.

Thanks, those instructions appear to have worked.

For comparison purposes, the equivalent steps in svn would be

svn diff -r PREV:HEAD --internal-diff > patchfile

and then the patchfile could be sent to the maintainer.

Duncan Murdoch

>
> G.
>
> On Wed, Jan 24, 2018 at 11:56 PM, Duncan Murdoch
> <[hidden email]> wrote:
>> On 24/01/2018 6:35 PM, Gábor Csárdi wrote:
>>>
>>> When you create a branch for your bug fix, don't create it off the
>>> previous fix. Create it off the original, forked state of the repo.
>>
>>
>> Branches keepclass2 through to keepclass5 are my attempts to do that. As far
>> as I can see they are all the same as keepclass, which was branched from the
>> head of the master branch of my fork.
>>>
>>>
>>> Are the two commits here your fixes?
>>> https://github.com/dmurdoch/manipulateWidget/commits/master
>>
>>
>> Those are both part of the first PR.  There's a third commit in keepclass
>> (and the other branches too...)
>>
>> If you or someone else tells me the magic commands I need to do what I want,
>> I'll appreciate it.  But the main point of my post is that this is something
>> that should be easy.  It shouldn't require expert help.  The fact that it
>> does is a flaw in the design of Git or Github or both.
>>
>> Duncan Murdoch
>>
>>
>>>
>>> Gabor
>>>
>>> On Wed, Jan 24, 2018 at 11:17 PM, Duncan Murdoch
>>> <[hidden email]> wrote:
>>>>
>>>> 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
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Gábor Csárdi
On Thu, Jan 25, 2018 at 12:24 AM, Duncan Murdoch
<[hidden email]> wrote:
[...]
> Thanks, those instructions appear to have worked.
>
> For comparison purposes, the equivalent steps in svn would be
>
> svn diff -r PREV:HEAD --internal-diff > patchfile
>
> and then the patchfile could be sent to the maintainer.

If you just want the diff corresponding to the last commit,

git show

will print it for you. Or

git show keepclass

for a specific branch.

G.

[...]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Duncan Murdoch-2
On 24/01/2018 7:29 PM, Gábor Csárdi wrote:

> On Thu, Jan 25, 2018 at 12:24 AM, Duncan Murdoch
> <[hidden email]> wrote:
> [...]
>> Thanks, those instructions appear to have worked.
>>
>> For comparison purposes, the equivalent steps in svn would be
>>
>> svn diff -r PREV:HEAD --internal-diff > patchfile
>>
>> and then the patchfile could be sent to the maintainer.
>
> If you just want the diff corresponding to the last commit,
>
> git show
>
> will print it for you. Or
>
> git show keepclass
>
> for a specific branch.

But that's only half the battle.  If I did that and emailed the diff to
a maintainer, I'm guessing I'd be told I should put together a PR
instead.  And as I found out, that's not easy, if I already have a fork
of the repository that contains changes and I don't want to blow it away.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Gábor Csárdi
On Thu, Jan 25, 2018 at 12:43 AM, Duncan Murdoch
<[hidden email]> wrote:
[...]
> But that's only half the battle.  If I did that and emailed the diff to a
> maintainer, I'm guessing I'd be told I should put together a PR instead.
> And as I found out, that's not easy, if I already have a fork of the
> repository that contains changes and I don't want to blow it away.

You can always create a branch, off any commit in the DAG, as in the
previous emails,
and then replay the changes there.

But there are alternatives as well, e.g. you can also create a branch
from the tip of master,
and then remove the two old commits, and keep the last one. I usually
do this via sg like

git rebase HEAD^^^^ --interactive

which will start an editor with the 4 latest commits. Then you just
remove the ones
you don't want, save, exit, and then git will perform the rebase, as desired.

G.

> Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Iñaki Úcar
In reply to this post by Duncan Murdoch-2
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 <[hidden email]>:

> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Duncan Murdoch-2
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 <[hidden email]>:
>> 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
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Dirk Eddelbuettel

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 <[hidden email]>:
| >> 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
| >>
| >> ______________________________________________
| >> [hidden email] mailing list
| >> https://stat.ethz.ch/mailman/listinfo/r-devel
| >
| >
| >
|
| ______________________________________________
| [hidden email] mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Iñaki Úcar
In reply to this post by Duncan Murdoch-2
2018-01-25 12:20 GMT+01:00 Duncan Murdoch <[hidden email]>:

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

Sorry for the confusion: the step of renaming your master branch isn't
really needed, because you can pull the original master branch and
call it whatever you want in one command. The process is as follows:

1) Add the upstream repo as another remote:

git remote add upstream https://github.com/the/original/repo

2) Pull the upstream master with a different name:

git pull upstream master:patch2

3) Edit, add, commit and push patch2 to your fork:

git checkout patch2
...
git push origin patch2

4) open a fresh new PR from "patch2" (the first one is intact).

Iñaki

>
> Duncan Murdoch
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Duncan Murdoch-2
In reply to this post by Dirk Eddelbuettel
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.

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 <[hidden email]>:
> | >> 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
> | >>
> | >> ______________________________________________
> | >> [hidden email] mailing list
> | >> https://stat.ethz.ch/mailman/listinfo/r-devel
> | >
> | >
> | >
> |
> | ______________________________________________
> | [hidden email] mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Duncan Murdoch-2
In reply to this post by Iñaki Úcar
On 25/01/2018 7:03 AM, Iñaki Úcar wrote:

> 2018-01-25 12:20 GMT+01:00 Duncan Murdoch <[hidden email]>:
>> 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.)
>
> Sorry for the confusion: the step of renaming your master branch isn't
> really needed, because you can pull the original master branch and
> call it whatever you want in one command. The process is as follows:

Thanks. I've tried some of this, and am a little confused.

>
> 1) Add the upstream repo as another remote:
>
> git remote add upstream https://github.com/the/original/repo
>
> 2) Pull the upstream master with a different name:
>
> git pull upstream master:patch2

I've done all that, and now on my local copy I have a branch.  I called
it "upstreamMaster", because at this point it matches the upstream
master, and I intend to maintain it that way.

>
> 3) Edit, add, commit and push patch2 to your fork:
>
> git checkout patch2
> ...
> git push origin patch2

I did this, except that the "..." contains nothing, because I want this
branch to continue.

But now my problem is that I can't see any way to tell Github about this
new branch.  I ran

git push origin upstreamMaster

and got

Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/dmurdoch/manipulateWidget
  * [new branch]      upstreamMaster -> upstreamMaster

but that branch doesn't show up in the Github web site.

Any suggestions?

Duncan Murdoch

>
> 4) open a fresh new PR from "patch2" (the first one is intact).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Gábor Csárdi
On Thu, Jan 25, 2018 at 12:34 PM, Duncan Murdoch
<[hidden email]> wrote:
[...]
> but that branch doesn't show up in the Github web site.

It is right there:
https://github.com/dmurdoch/manipulateWidget/branches

> Any suggestions?

Personally I would suggest to call it master, because it is just
easier. Your master should correspond to the upstream master, and you
can do your own stuff in other branches.

G.

[...]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Joris FA Meys
In reply to this post by Duncan Murdoch-2
Hi Duncan,

I can see that branch on your github. Remember that you have to reload the
github page to see the latest additions to your repo. It doesn't do that
automatically.

Cheers
Joris

On Thu, Jan 25, 2018 at 1:34 PM, Duncan Murdoch <[hidden email]>
wrote:

> On 25/01/2018 7:03 AM, Iñaki Úcar wrote:
>
>> 2018-01-25 12:20 GMT+01:00 Duncan Murdoch <[hidden email]>:
>>
>>> 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.)
>>>
>>
>> Sorry for the confusion: the step of renaming your master branch isn't
>> really needed, because you can pull the original master branch and
>> call it whatever you want in one command. The process is as follows:
>>
>
> Thanks. I've tried some of this, and am a little confused.
>
>
>> 1) Add the upstream repo as another remote:
>>
>> git remote add upstream https://github.com/the/original/repo
>>
>> 2) Pull the upstream master with a different name:
>>
>> git pull upstream master:patch2
>>
>
> I've done all that, and now on my local copy I have a branch.  I called it
> "upstreamMaster", because at this point it matches the upstream master, and
> I intend to maintain it that way.
>
>
>> 3) Edit, add, commit and push patch2 to your fork:
>>
>> git checkout patch2
>> ...
>> git push origin patch2
>>
>
> I did this, except that the "..." contains nothing, because I want this
> branch to continue.
>
> But now my problem is that I can't see any way to tell Github about this
> new branch.  I ran
>
> git push origin upstreamMaster
>
> and got
>
> Total 0 (delta 0), reused 0 (delta 0)
> To https://github.com/dmurdoch/manipulateWidget
>  * [new branch]      upstreamMaster -> upstreamMaster
>
> but that branch doesn't show up in the Github web site.
>
> Any suggestions?
>
> Duncan Murdoch
>
>
>> 4) open a fresh new PR from "patch2" (the first one is intact).
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel




--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>

-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Mario Emmenlauer
In reply to this post by Duncan Murdoch-2

Hi Duncan!

I think there are many users whose first experiences with git where frustrating,
and trust me, many people here can relate to your pain. I can certainly say that
I can. At first, git makes significant effort to become fluent in seemingly
"simple" tasks. I can literally feel your pain right now.


But this is the main downside of git: that it can be hard to learn. I overcame
this problem by collecting copy-paste-instructions for the most common tasks.
I think Dirk provided a very nice starting point for a typical pull request, and
next time you need to use git, maybe try his instructions. They are *exactly* what
I use at least once a week. However they are not 1:1 for your current situation,
where you already started a fork.

If you want to solve your current "mess", I personally find the easiest thing to
move all local changes away (to /tmp/ or wherever), trash the github fork, and
start over with Dirks instructions. At point (4) you can copy your changed files
back from /tmp/ and use them for new commits, in this new, clean branch.

Everything else should just work.

Cheers,

    Mario




On 25.01.2018 13:09, 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.
>
> 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 <[hidden email]>:
>> | >> 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
>> | >>
>> | >> ______________________________________________
>> | >> [hidden email] mailing list
>> | >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> | >
>> | >
>> | >
>> |
>> | ______________________________________________
>> | [hidden email] mailing list
>> | https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Jari Oksanen
This is exactly the instruction given in  https://xkcd.com/1597/

cheers, J.O.

On 25/01/18 14:48, Mario Emmenlauer wrote:

> Hi Duncan!
>
> I think there are many users whose first experiences with git where frustrating,
> and trust me, many people here can relate to your pain. I can certainly say that
> I can. At first, git makes significant effort to become fluent in seemingly
> "simple" tasks. I can literally feel your pain right now.
>
>
> But this is the main downside of git: that it can be hard to learn. I overcame
> this problem by collecting copy-paste-instructions for the most common tasks.
> I think Dirk provided a very nice starting point for a typical pull request, and
> next time you need to use git, maybe try his instructions. They are *exactly* what
> I use at least once a week. However they are not 1:1 for your current situation,
> where you already started a fork.
>
> If you want to solve your current "mess", I personally find the easiest thing to
> move all local changes away (to /tmp/ or wherever), trash the github fork, and
> start over with Dirks instructions. At point (4) you can copy your changed files
> back from /tmp/ and use them for new commits, in this new, clean branch.
>
> Everything else should just work.
>
> Cheers,
>
>      Mario
>
>
>
>
> On 25.01.2018 13:09, 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.
>>
>> 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 <[hidden email]>:
>>> | >> Lately I've been doing some work with the manipulateWidget package, which
>>> | >> lives on Github at
>>> | >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frte-antares-rpackage%2FmanipulateWidget%2F&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=uJhNCEY4egYlpDCkoGy6mI3WRb5PbkgZiBeCDsurxdg%3D&reserved=0.  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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdmurdoch%2FmanipulateWidget&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=44irdj5wUdiaOR86LBckjNkHq1QosEZaqIapyXLJw0Q%3D&reserved=0>.
>>> | >>
>>> | >> - I checked out my fork into RStudio.
>>> | >>
>>> | >> - I fixed the bug, and submitted the pull request
>>> | >> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frte-antares-rpackage%2FmanipulateWidget%2Fpull%2F47&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=v2iC1pRbfMGg5lWNYiKbbJ6qILU%2FOwn6V9U4pEJx2cs%3D&reserved=0>.
>>> | >>
>>> | >> 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
>>> | >>
>>> | >> ______________________________________________
>>> | >> [hidden email] mailing list
>>> | >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=4SGKvj20hKYiBbbUjsV8tgItxsjAMYmTtJQX0yr8V%2Bs%3D&reserved=0
>>> | >
>>> | >
>>> | >
>>> |
>>> | ______________________________________________
>>> | [hidden email] mailing list
>>> | https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=4SGKvj20hKYiBbbUjsV8tgItxsjAMYmTtJQX0yr8V%2Bs%3D&reserved=0
>>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=4SGKvj20hKYiBbbUjsV8tgItxsjAMYmTtJQX0yr8V%2Bs%3D&reserved=0
>
>
> Viele Gruesse,
>
>      Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
> Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
> D-81669 München                          https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.biodataanalysis.de%2F&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=YcW8DMm%2F%2FSSzWVIiZHwwVZClxz9bl911vECahW2Ynt0%3D&reserved=0
>
> ______________________________________________
> [hidden email] mailing list
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7C%7Cd46f88a5d3664fd3163f08d563f1ebab%7C9f9ce49a51014aa38c750d5935ad6525%7C0%7C1%7C636524813075970616&sdata=4SGKvj20hKYiBbbUjsV8tgItxsjAMYmTtJQX0yr8V%2Bs%3D&reserved=0

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why R should never move to git

Martin Morgan-3
In reply to this post by Duncan Murdoch-2
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 <[hidden email]>:
>> | >> 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
>> | >>
>> | >> ______________________________________________
>> | >> [hidden email] mailing list
>> | >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> | >
>> | >
>> | >
>> |
>> | ______________________________________________
>> | [hidden email] mailing list
>> | https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


This email message may contain legally privileged and/or...{{dropped:2}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
12