+1 I want to show the code I have done from edX courses to potential employers, but I can't make them public due to edX's honor code, It would be usefull to have a way of granting by an URL, view only permission to a private repository, just like in google drive for example.
That's kind of an obvious need in my view.
My specific situation is I'm freelancing and want to give read access to my client.
I just discovered the option of private repositories in the announcement. Just like stated, I use them to 'apply for a job'. That's even the only usage I make of them, besides experimenting with Git and Github.
So, I would like to selectively give access to people, like by supplying an URL with a key. As I know from photo albums on the web. This should be ready only, which may include copying or cloning, preferably copying.
So that is my request, which seems pretty obvious to me.
By the way, I do not consider this 'solved'. That is more of an euphemism to get rid of the question.
It seems to me that the git/GitHub owners, by assuming that there is only one use-case for git/GitHub (shared open software development), are limiting the usefulness of GitHub. Some of the postings in this thread show other use cases that require readonly access to files for one audience yet require pulling/pushing/versions/branches to the developers.
An additional use case that occurs to me is using GitHub to make a portion of a proprietary product public. We always assume that a product is either proprietary or open, but not both. But I can easily imagine products that are proprietary and sold for profit, yet contribute a new and useful subroutine or algorithm to the Open Software community. In such a case the developers might want to use GitHub to collaborate in private, but might want one specific file to be readonly or read/write visible to the public.
Addition to message #21:
Another use case for fine-grained permissions is when a commit concerns a security problem. The changed files in such a commit should be visible only to the author and to those who manage security updating. In case it isn't obvious, the reason is that making these files readonly or read/write might leak compromise information to malicious users when the repository access is public.
Also, it might be helpful to note here that the Google Gerrit Code Review process and tools, built on top of git, already provide such fine-grained permissions, but at the expense of a very detailed workflow as compared with either git or GitHub.
Guess there arent any news in this subject right? is there an open ticket to implement the feature at least? What alternatives are you using? I really dont want to duplicate my repos, plus downloading is different from consulting
Our product team is definitely discussing new features to make collaboration of different types easier on GitHub. However, nothing on this front has shipped as of yet. Any new features will be announced in the GitHub Changelog, so I'd recommend keeping an eye on that page for updates.
As for collaborating on projects where you want someone to be able to work on a portion of the codebase but not the entire codebase, it might be worth breaking your codebase into smaller, reusable pieces. Then you could add someone as a collaborator on a repository that only has access to the smaller piece of the whole and you can use continuous integration to make sure that changing code in one piece doesn't break the overall codebase.
Hope that helps!
Yea.. that was my next question, if it was possible to restrict users to certain folders.
I came up with some workarrounds to fix these problems
Would be VERY useful to be able to share a URL (and key?) for read only accesses
As some have mentioned. I have clients that would like to review my code, but still limit their access to specific files/folders. And the same for private code that could be shared with potential clients to give them an idea about the quality of work that can be provided, and so on.
If perhaps there were permissions for specific files/folders with a timeout option. That way, there wouldn't be a need to revoke permissions at a later date.