Re: [Rd] Why R should never move to git

[Juan Telleria Ruiz de Aguirre]

I attach the Github Flow for teams and projects with regular deployments:

https://guides.github.com/pdfs/githubflow-online.pdf

https://guides.github.com/introduction/flow/

Tips:
* Always Do pull requests based on branches (never on the master).
* Keep your Fork Synchronized with the Upstream Repository.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Juan Telleria Ruiz de Aguirre]

> 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 have been doing some tests, and I think that this issue can be
easily addressed with Bitbucket GUI (https://bitbucket.org/product),
which is free for Open Source Projects
(https://www.atlassian.com/software/views/open-source-license-request)
and seems easy to use (So it follows the K.I.S.S. principle).

Just another alternative instead of Gitlab for self-hosting... no worries.

Best,
Juan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Juan Telleria Ruiz de Aguirre]

Yes, indeed Gitlab GUI Core Code is Open Source (Libre / Community
Edition): https://gitlab.com/gitlab-org/gitlab-ce

> But his instructions required command-line git, and my main claim is that 
> Github is not good enough to do the kinds of things I want to do and R Core 
> would need to do.
>
> My other claim is that git is too hard to use.

I'm sure that Git Command Line Recipe Documentation can solve this
issue, Gitlab, in particular, has a wiki in which this kind of issues
could be documented. Also Git cheat-sheets might prove useful. In
addition, any feature request could be done in Gitlab Issue Section
(See above), or if that does not still does not convince, other
options could be considered, such as Bitbucket
(https://bitbucket.org/), etc.

In addition, the Git Repository:
* Could be self-hosted in the University Servers (Just as SVN actually
is nowadays).
* Be accessed either by the Command Line or the Graphical User
Interface (As users prefer).

The main reason motivating the move to the GIT Repository, as said
before, is that it would to allow individual users or companies from
the R Consortium to do pull requests based on issues for improving
base R code.

Indeed, in some years from now I would like to help to improve base R
myself, maybe re-writing some parts of the code in C++, fixing bugs,
or who knows :)

Kind regards,
Juan Telleria

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Suzen, Mehmet]

On 31 January 2018 at 16:18, Barry Rowlingson
 wrote:
>>
>
> Let the record also state that *gitlab* is an open source project and can be
> downloaded and self-hosted, like gogs, but unlike github.


Good to know. Nice one: https://github.com/gitlabhq/gitlabhq

Best,
-m


> PS I've been running a gitlab instance for my group for a couple of years on
> a private server.

Is it a smooth ride so far?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Barry Rowlingson]

On Tue, Jan 30, 2018 at 11:07 PM, Suzen, Mehmet 
wrote:

> This might be off topic, but if R-core development ever moves to git,
> I think it would make sense to have its own git service hosted by a
> university, rather than using
> github or gitlab. It is possible via https://gogs.io/ project.
>
> Just for the record.
>
>
Let the record also state that *gitlab* is an open source project and can
be downloaded and self-hosted, like gogs, but unlike github.

Barry

PS I've been running a gitlab instance for my group for a couple of years
on a private server.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Suzen, Mehmet]

Gabor, I was just pointing out options. I think it is more of a policy
decision than a technical one. For example, the very mailing list we
are using is run by ETH Zurich with Martin Maechler. But it can well
be run on google groups. Maybe this list should also move to google
groups, it is unlikely that Google would shut down google groups soon.

Best,
-m

On 31 January 2018 at 00:26, Gábor Csárdi  wrote:
> While this is a very hypothetical argument, you could at least explain
> _why_ you would think so.
>
> If you were thinking about the unlikely event of GitHub / GitLab
> closing business, that is _not_ such a big to any active project that
> is hosted there.
>
> Gabor
>
> On Tue, Jan 30, 2018 at 11:07 PM, Suzen, Mehmet  
> wrote:
>> This might be off topic, but if R-core development ever moves to git,
>> I think it would make sense to have its own git service hosted by a
>> university, rather than using
>> github or gitlab. It is possible via https://gogs.io/ project.
>>
>> Just for the record.
>>
>> Best,
>> -m
>>
>> __
>> 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

Re: [Rd] Why R should never move to git

[Gábor Csárdi]

While this is a very hypothetical argument, you could at least explain
_why_ you would think so.

If you were thinking about the unlikely event of GitHub / GitLab
closing business, that is _not_ such a big to any active project that
is hosted there.

Gabor

On Tue, Jan 30, 2018 at 11:07 PM, Suzen, Mehmet  wrote:
> This might be off topic, but if R-core development ever moves to git,
> I think it would make sense to have its own git service hosted by a
> university, rather than using
> github or gitlab. It is possible via https://gogs.io/ project.
>
> Just for the record.
>
> Best,
> -m
>
> __
> 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

Re: [Rd] Why R should never move to git

[Suzen, Mehmet]

This might be off topic, but if R-core development ever moves to git,
I think it would make sense to have its own git service hosted by a
university, rather than using
github or gitlab. It is possible via https://gogs.io/ project.

Just for the record.

Best,
-m

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Juan Telleria Ruiz de Aguirre]

In case it's useful:

A) Git Cheatsheet: ADVANCED (GitHub)

https://www.google.es/url?sa=t&source=web&rct=j&url=https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf&ved=2ahUKEwjkhYmdt_bYAhXIwBQKHXWdBfoQFjAAegQIERAB&usg=AOvVaw3RoN21aynhcDHqKncV31el

B) Git Cheatsheet: BASICS (GitHub)

https://www.google.es/url?sa=t&source=web&rct=j&url=https://education.github.com/git-cheat-sheet-education.pdf&ved=2ahUKEwjkhYmdt_bYAhXIwBQKHXWdBfoQFjABegQIEhAB&usg=AOvVaw2D3W2R0fwoOBi8YrhZYLFJ

C) Git Cheatsheet (Atlassian)

https://www.google.es/url?sa=t&source=web&rct=j&url=https://www.atlassian.com/dam/jcr:8132028b-024f-4b6b-953e-e68fcce0c5fa/atlassian-git-cheatsheet.pdf&ved=2ahUKEwjkhYmdt_bYAhXIwBQKHXWdBfoQFjACegQIExAB&usg=AOvVaw2TdLUeHteS2YU_G9u_-6nP

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Juan Telleria Ruiz de Aguirre]

I do not mind investing as much time as necessary :-)

> If you ever need to document issues / coding recipes related to GIT / SVN:
>
> * I could pick the commands from e-mails.
> * Any documentation you send me.
> * Or books (http://shop.oreilly.com/product/0636920022862.do), web pages,
etc..
>
> And create a wiki / documentation page in any platform, in order to help.
>
> Best,
> Juan

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Juan Telleria Ruiz de Aguirre]

If you ever need to document issues / coding recipes related to GIT / SVN:

* I could pick the commands from e-mails.
* Any documentation you send me.
* Or books (http://shop.oreilly.com/product/0636920022862.do), web pages,
etc..

And create a wiki / documentation page in any platform, in order to help.

Best,
Juan

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Iñaki Úcar]

2018-01-25 16:07 GMT+01:00 Duncan Murdoch :
> On 25/01/2018 7:44 AM, Gábor Csárdi wrote:
>>
>> On Thu, Jan 25, 2018 at 12:34 PM, Duncan Murdoch
>>  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.
>
>
> That makes sense, but I don't see a way to rename branches on Github.  I did
> see a way to make it my default branch, but there's a scary warning:
>
> "Are you sure?
>
> Changing your default branch can have unintended consequences that can
> affect new pull requests and clones."
>
> To answer yes to this I would have to say "I understand, update the default
> branch", and since I don't understand the consequences, I didn't click it.

Changing the default branch just moves the HEAD pointer (on GitHub) to
another branch. It would be equivalent to ssh into GitHub's server, cd
into the repo, and enter "git checkout anotherbranch". So not a big
deal in principle, but anyway this doesn't make any difference in this
case.

Also note that the name is not important: "master" has no special
meaning as "trunk" does in svn. It's just a convention, no more.

The executive summary of this thread would be:

1. Keep the default branch synced with upstream (this is usually
"master", but it could be another), and use other branches to fix
things and submit PRs.
2. If you mistakenly committed and pushed something to it, no problem:
just fetch a fresh copy of that branch from upstream and call it by a
different name, and we're back in 1.
3. GitHub can't be blamed about how git works. ;-)

Iñaki

>
> Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

On 25/01/2018 7:44 AM, Gábor Csárdi wrote:

On Thu, Jan 25, 2018 at 12:34 PM, Duncan Murdoch
 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.


That makes sense, but I don't see a way to rename branches on Github.  I 
did see a way to make it my default branch, but there's a scary warning:


"Are you sure?

Changing your default branch can have unintended consequences that can 
affect new pull requests and clones."


To answer yes to this I would have to say "I understand, update the 
default branch", and since I don't understand the consequences, I didn't 
click it.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

On 25/01/2018 7:44 AM, Joris Meys wrote:

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.


Thanks, that was the issue.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Martin Morgan]

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

Re: [Rd] 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 :
| >> 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.c

Re: [Rd] Why R should never move to git

[Mario Emmenlauer]

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 :
>> | >> Lately I've been doing some work with the manipulateWidget package, 
>> whi

Re: [Rd] Why R should never move to git

[Joris Meys]

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

> On 25/01/2018 7:03 AM, Iñaki Úcar wrote:
>
>> 2018-01-25 12:20 GMT+01:00 Duncan Murdoch :
>>
>>> 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).
>>
>
> __
> R-devel@r-project.org 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)


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

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

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Gábor Csárdi]

On Thu, Jan 25, 2018 at 12:34 PM, Duncan Murdoch
 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.

[...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

On 25/01/2018 7:03 AM, Iñaki Úcar wrote:

2018-01-25 12:20 GMT+01:00 Duncan Murdoch :

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


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

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 :
| >> 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
| >> .
| >>
| >> - I checked out my fork into RStudio.
| >>
| >> - I fixed the bug, and submitted the pull request
| >> .
| >>
| >> 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

Re: [Rd] Why R should never move to git

[Iñaki Úcar]

2018-01-25 12:20 GMT+01:00 Duncan Murdoch :
> 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
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 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 :
| >> 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
| >> .
| >>
| >> - I checked out my fork into RStudio.
| >>
| >> - I fixed the bug, and submitted the pull request
| >> .
| >>
| >> 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/lis

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

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 :

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
.

- I checked out my fork into RStudio.

- I fixed the bug, and submitted the pull request
.

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

Re: [Rd] Why R should never move to git

[Iñaki Úcar]

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 :
> 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
> .
>
> - I checked out my fork into RStudio.
>
> - I fixed the bug, and submitted the pull request
> .
>
> 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



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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Gábor Csárdi]

On Thu, Jan 25, 2018 at 12:43 AM, Duncan Murdoch
 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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

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

On Thu, Jan 25, 2018 at 12:24 AM, Duncan Murdoch
 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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Gábor Csárdi]

On Thu, Jan 25, 2018 at 12:24 AM, Duncan Murdoch
 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.

[...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

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

- I checked out my fork into RStudio.

- I fixed the bug, and submitted the pull request
.

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

Re: [Rd] 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
 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
>>  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
>>> .
>>>
>>> - I checked out my fork into RStudio.
>>>
>>> - I fixed the bug, and submitted the pull request
>>> .
>>>
>>> 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

Re: [Rd] Why R should never move to git

[Duncan Murdoch]

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

- I checked out my fork into RStudio.

- I fixed the bug, and submitted the pull request
.

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

Re: [Rd] Why R should never move to git

[Hugh Parsonage]

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  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
> .
>
> - I checked out my fork into RStudio.
>
> - I fixed the bug, and submitted the pull request
> .
>
> 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

Re: [Rd] 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
 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
> .
>
> - I checked out my fork into RStudio.
>
> - I fixed the bug, and submitted the pull request
> .
>
> 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

[Rd] Why R should never move to git

[Duncan Murdoch]

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 
.


- I checked out my fork into RStudio.

- I fixed the bug, and submitted the pull request 
.


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