http://pages.github.com/ may work for content distribution (lecture notes).Perhaps http://www.gitbook.com/ for the course materials -- possibly in conjunction with http://gist.github.com/ (posting code snippets).That being said, it is not a course platform in general.There are specialized platforms, e.g., https://open.edx.org/However, if it is for a course you're teaching, then having your students upload the code into a version controlled repository may actually be useful.Two solutions:http://bitbucket.org/ offers private repositories for free (Git support included)http://education.github.com/ offers private repositories for students (needs status verification)You could even add hooks -- and possibly CI (note: not aware of any free ones for private repositories) -- to verify basic build success, style, etc. (e.g., to save yourself some time from evaluating non-functional submissions).See: http://githooks.com/This may be worth reading for a more detailed experience & advice: http://joshldavis.com/2014/06/30/github ... follow-up/

Anyone hit by this?

GitLab.com Melts Down After Wrong Directory Deleted, Backups Fail

General question. Is this gitesque approach useful for online courses, code distributions, forums etc. instead of let's say a phpBB?

Code contributions are quite obviously simpler with GitHub. Hell, phpBB is bad for almost anything  Distributions... GitHub used to be good at that; not any more, as far as I can tell — you may be better off hosting the files on AWS and just linking to those from github pages/wiki.

Git as a forum isn't that good; on the other hand, I can see extensive discussions in github issues, see e.g. https://github.com/Reactive-Extensions/Rx.NET/issues/19

For online courses, I cannot see a point. Having said that, no MOOC I saw so far (and I've finished a dozen) had a good forum. Slack groups work well for that, sites... meh.

Any Github-specific licensing issues to be warned against?

I think public repositories *used* to be required to be open-source, but I think it's longer a requirement. The link you gave just says that "most people" use public repositories for open-source projects, but it's that it's a requirement ?

Is your project open source?

If I were to upload code on Github, it would be small pieces, no 'real' projects, and the main goal would be I have them accessible from everywhere. So, I would definetely be OK for people to use, share, change, ... Maybe I would also like to be able to track how people use and improve my stuff. Hopefully, it will get me back some new ideas.

Sounds good! To stimulate that it would be wise to clearly pick an open source licence? MIT or GPL? That way people won't have to worry if it's allowed.

Also add "copyright tagoma" to be safe I would say?

AFAIK one can pay for a private repository on GitHub.

I have a private (paid) account ($7/month, unlimited repositories)

Still don't trust it to be private! I guess the only way to get some certainty is client side encryption? 

Obviously, some American company still have access to your code, private account or not. I'd never upload my proprietary software.
BTW, this is a licence note I copied from somewhere:
https://github.com/rilwen/open-quantum- ... /README.md
Feel free to copy the relevant part.

yes, so that's why you needs to only send encrypted data to the github private repo.

perhaps this? https://github.com/AGWA/git-crypt

Please forgive if this is a silly question on my part, but am I missing something regarding the comments about encrypting uploads to github?
git (regardless of whether hosted on github or elsewhere) depends upon SHA signatures to determine if a particular object or element within a repository has changed, and thereby needing to have the latest copy of that object uploaded to the repo server.  SHA is effectively itself a form of encryption.  Depending on your encryption scheme, if you re-encrypt all files every time you do a push, then you run the risk of most of your files needing to be uploaded for every push.  That would explode your space consumption on whichever server is hosting you.  To avoid that, you might need to create a makefile to only re-encrypt those files which have changed.  You would also need to define your repository to keep the ciphertext & plaintext files in separate directories, or else explicitly configure the repo to exclude the plaintext files.  To exclude the plaintext files from the repo, wouldn't you need to effectively hide them from the repo?  If you do that, then aren't you giving up the ability to run commands like "git blame" ?

The point is not whether you trust the particular brand github.  If you need ciphertext storage in a repo server then git would seem to be an inelegant platform.

Or, perhaps someone else has figured a solution for all these objections, and perhaps I'm a bit behind the times ?

That's IMO exactly what you would do. Encrypt​ing a file will give the same result as long as the source file is the same, (and thus the SHA with be the same) so you can encrypt files on the fly: only changed source files will end up getting stored.

I agree it's a hack, still better than nothing, it's the only way to control yourself who sees the files.

These are more advanced techniques that allow for intelligent queries on encrypted data without decrypting (CryptDB eg), or have groups of users have their own keys (like in WhatsApp) that I think are cool, but that would require modifications on the server side of git I guess?

It depends on each encryption algorithm whether or not you get the exact same ciphertext each time you encrypt the plaintext.  This is a deliberate choice on the part of each cipher designer.

The point of a git repo server is that all clones should have the exact same content, such that anytime you snap a copy onto some other machine you would still get the exact same result.
If you have some files/scripts/wrappers for handling the conversion between plainttext<->ciphertext then you have something which is not getting pushed up to the repo server.
Or, the wrappers end up being their own separate repo of utilities for converting between ciphertext & plaintext, with the only missing part being the key itself.

"git blame" does not need to be run up on the server.  However, to look at the history of changes to the plaintext version of the repo, I suspect you would need to define a separate repo of the plaintext collection which never gets pushed to the server, but gets encrypted as a bundle and then that entire bundle would need to be what gets pushed to the server.

The minute you pursue that approach it seems you would lose the benefits of only storing deltas and you end up with many redundant copies of your entire repo, padded by all the overhead of encryption.  If your gonna do that, it seems you'd explode your space consumption and then you lose the benefits of using a repo hosting service.

I think I'm starting to repeat myself here :-/