On 21/04/2015 00:35, Vladimir Panteleev wrote:
<snip>
>> In the other thread I referred to this
>> http://stackoverflow.com/questions/5010754/github-collaborators-have-commit-access
>> which makes it sound as though it's possible to do the same thing in GitHub.  Is that
>> page wrong?
>
> This question pertains to private GitHub repositories (a feature of paid plans).

One of the comments there: "Or you make your repository public, then everyone (who is not a collaborator) has read-only access"

And everyone who _is_ a collaborator has what?

> Regardless, I do not recommend attempting to shoehorn your previous SVN workflow into git
> and GitHub. The usual way contributions are done with GitHub is that anyone with a GitHub
> account can create a pull request (a series of commits, initially published on their own
> fork of the repository), which the repository owner (or collaborators) can then accept
> (merge) into the main repository.

https://en.wikipedia.org/wiki/Fork_%28software_development%29
implies that a fork is a divergent development branch - a separate copy of the project that has no ongoing link to the original.  Is the Git concept of a fork different?

> Instead of designating a group of committers as in SVN,
> you would simply need to review pull requests and click the "merge" button to accept them.
> If you do not foresee yourself being available often enough to review/accept pull
> requests, you can designate a few collaborators who can do it as well.

Maybe I'll do that.  Most of the time I should be available enough, but there's always the chance that I'll be away for a week every now and again (possibly longer if I'm lucky).

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.

On 2015-04-22 00:06, Stewart Gordon wrote:

> One of the comments there: "Or you make your repository public, then
> everyone (who is not a collaborator) has read-only access"
>
> And everyone who _is_ a collaborator has what?

Push access (svn would call this commit access). I don't think collaborators have access to the settings of the project thought. Perhaps that is dependent on what role the collaborator has.

> https://en.wikipedia.org/wiki/Fork_%28software_development%29
> implies that a fork is a divergent development branch - a separate copy
> of the project that has no ongoing link to the original.  Is the Git
> concept of a fork different?

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.

-- 
/Jacob Carlborg

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.

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

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/

On Saturday, 25 April 2015 at 03:36:24 UTC, Rikki Cattermole wrote:
> [0] http://www.sourcetreeapp.com/

Git got a proper visualization of commit tree? :)

On 28/04/2015 12:56 a.m., Kagamin wrote:
> On Saturday, 25 April 2015 at 03:36:24 UTC, Rikki Cattermole wrote:
>> [0] http://www.sourcetreeapp.com/
>
> Git got a proper visualization of commit tree? :)

Better then anything else out there!

So, four months later, can we have some kind of warning banner on dsource.org?

On Friday, 21 August 2015 at 17:05:42 UTC, tired_eyes wrote:
> So, four months later, can we have some kind of warning banner on dsource.org?

Done.

On Saturday, 22 August 2015 at 13:03:34 UTC, Vladimir Panteleev wrote:
> On Friday, 21 August 2015 at 17:05:42 UTC, tired_eyes wrote:
>> So, four months later, can we have some kind of warning banner on dsource.org?
>
> Done.

Excellent, thank you! It was a source of confusion.