Re: Trial migration of Dsource bindings project to Github
On Tuesday, 21 April 2015 at 21:31:39 UTC, Stewart Gordon wrote: How does using SVN lead to fragmentation? I don't understand. See http://forum.dlang.org/post/mailman.3160.1418550079.9932.digitalmar...@puremagic.com
Re: dsource.org moved
On Friday, 24 April 2015 at 21:48:30 UTC, Stewart Gordon wrote: On 22/04/2015 08:20, Jacob Carlborg wrote: snip If you're forking a project on Github you get your own copy of the project. The projects are linked but the repositories are not. What I mean by that is on your fork you'll see that it is a fork with a link back to the original project. From the original project you can also view all forks. The repositories are not linked in the sense that there's no automatic syncing of code between them. The fork needs to manually pull from the original repository to get the latest changes. I guess the word link has too many meanings. :p So a fork is really a working copy of the master repository, and the code that the user will typically edit is in turn a working copy of this. And commit and push in Git terms basically mean to commit to the local fork and to commit the fork to the master repo respectively. So if pull means to update one's fork, what is a pull request requesting exactly? With git, technically, no repo is more important than another, since it's a distributed source control system rather than a centralized one. Everyone gets their own, independent repo, with its own commit history. Pushing and pulling and whatnot don't care about which repo is the primary repo or anything like that. It's just taking a set of commits from one repo and putting them in the other repo. Committing is _always_ to your local repo. You never commit to another repo. Pushing is when you control both repo A and repo B, and from the machine with repo A on it, you push a set of commits into repo B. It therefore requires that you have the permissions to manipulate repo A directly on the machine that it's on (since you're doing the operation on that machine) and that you have write permissions for repo B (since you're commanding repo B to take your commits from repo A). Pulling is when you do the commands from the machine with repo A on it and take the code from repo B and put it in repo A. You only need read permissions for repo B in that case (so it could be a public repo that you have no control over whatsoever). The typical workflow with github is that you create a branch on your local machine and make commits with whatever changes you're making. You then push that branch into your github repo for that project. So, you've created a branch there which then matches your local branch (and if you need to make further commits, those would have to be pushed separately). Then you create a pull request from your github repo for the target repo (typically the primary repo for the project, but it could be the repo of someone else you're working with). Typically, it's targeting the master branch of the target repo, but it could be for any branch in that repo. Whoever controls the target repo is notified of your pull request. They can then look over the code, suggest changes, etc. Once they're satisfied with it, they can hit the merge button on github. That tells github to pull the code from the branch in your github repo into the target repo. After that, anyone who pulls from the target repo will get your changes. And normally, you'd delete the branch that you used for that pull request and create a new one for whatever your next set of changes are. So, normally, you only push to your own github repo, and everything else is done via pulling. Now, you _can_ just push to the primary repo rather than your own github repo if you have the permissions for it, but then the code doesn't get reviewed, and only folks who have push permissions for that repo can do that (which most folks won't have). Operating that way is basically operating how svn operates, which pretty much everyone using git will tell you not to do. Hopefully, that explanation helps, but you really should read some of the guides out there for this, since they'll have pretty pictures (which can help considerably) and probably explain it better than I do. e.g. https://guides.github.com/introduction/flow/index.html http://nvie.com/posts/a-successful-git-branching-model/ https://blogs.atlassian.com/2014/01/simple-git-workflow-simple/ https://sandofsky.com/blog/git-workflow.html - Jonathan M Davis
Re: dsource.org moved
On 25/04/2015 3:33 p.m., Jonathan M Davis wrote: On Friday, 24 April 2015 at 21:48:30 UTC, Stewart Gordon wrote: On 22/04/2015 08:20, Jacob Carlborg wrote: snip If you're forking a project on Github you get your own copy of the project. The projects are linked but the repositories are not. What I mean by that is on your fork you'll see that it is a fork with a link back to the original project. From the original project you can also view all forks. The repositories are not linked in the sense that there's no automatic syncing of code between them. The fork needs to manually pull from the original repository to get the latest changes. I guess the word link has too many meanings. :p So a fork is really a working copy of the master repository, and the code that the user will typically edit is in turn a working copy of this. And commit and push in Git terms basically mean to commit to the local fork and to commit the fork to the master repo respectively. So if pull means to update one's fork, what is a pull request requesting exactly? With git, technically, no repo is more important than another, since it's a distributed source control system rather than a centralized one. Everyone gets their own, independent repo, with its own commit history. Pushing and pulling and whatnot don't care about which repo is the primary repo or anything like that. It's just taking a set of commits from one repo and putting them in the other repo. Committing is _always_ to your local repo. You never commit to another repo. Pushing is when you control both repo A and repo B, and from the machine with repo A on it, you push a set of commits into repo B. It therefore requires that you have the permissions to manipulate repo A directly on the machine that it's on (since you're doing the operation on that machine) and that you have write permissions for repo B (since you're commanding repo B to take your commits from repo A). Pulling is when you do the commands from the machine with repo A on it and take the code from repo B and put it in repo A. You only need read permissions for repo B in that case (so it could be a public repo that you have no control over whatsoever). The typical workflow with github is that you create a branch on your local machine and make commits with whatever changes you're making. You then push that branch into your github repo for that project. So, you've created a branch there which then matches your local branch (and if you need to make further commits, those would have to be pushed separately). Then you create a pull request from your github repo for the target repo (typically the primary repo for the project, but it could be the repo of someone else you're working with). Typically, it's targeting the master branch of the target repo, but it could be for any branch in that repo. Whoever controls the target repo is notified of your pull request. They can then look over the code, suggest changes, etc. Once they're satisfied with it, they can hit the merge button on github. That tells github to pull the code from the branch in your github repo into the target repo. After that, anyone who pulls from the target repo will get your changes. And normally, you'd delete the branch that you used for that pull request and create a new one for whatever your next set of changes are. So, normally, you only push to your own github repo, and everything else is done via pulling. Now, you _can_ just push to the primary repo rather than your own github repo if you have the permissions for it, but then the code doesn't get reviewed, and only folks who have push permissions for that repo can do that (which most folks won't have). Operating that way is basically operating how svn operates, which pretty much everyone using git will tell you not to do. Hopefully, that explanation helps, but you really should read some of the guides out there for this, since they'll have pretty pictures (which can help considerably) and probably explain it better than I do. e.g. https://guides.github.com/introduction/flow/index.html http://nvie.com/posts/a-successful-git-branching-model/ https://blogs.atlassian.com/2014/01/simple-git-workflow-simple/ https://sandofsky.com/blog/git-workflow.html - Jonathan M Davis Also if you are on Windows or OSX, use SourceTree[0]. I cannot recommend this enough. It'll install git, wrap it up nicely for you and even show pretty imagery regarding the current state of the repo! [0] http://www.sourcetreeapp.com/
Re: Trial migration of Dsource bindings project to Github
On 24/04/2015 11:58, Kagamin wrote: On Tuesday, 21 April 2015 at 21:31:39 UTC, Stewart Gordon wrote: How does using SVN lead to fragmentation? I don't understand. See http://forum.dlang.org/post/mailman.3160.1418550079.9932.digitalmar...@puremagic.com ?? I've had a quick look, and can't at the moment see what in that thread relates to using SVN. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On 22/04/2015 08:20, Jacob Carlborg wrote: snip If you're forking a project on Github you get your own copy of the project. The projects are linked but the repositories are not. What I mean by that is on your fork you'll see that it is a fork with a link back to the original project. From the original project you can also view all forks. The repositories are not linked in the sense that there's no automatic syncing of code between them. The fork needs to manually pull from the original repository to get the latest changes. I guess the word link has too many meanings. :p So a fork is really a working copy of the master repository, and the code that the user will typically edit is in turn a working copy of this. And commit and push in Git terms basically mean to commit to the local fork and to commit the fork to the master repo respectively. So if pull means to update one's fork, what is a pull request requesting exactly? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
