171–180 of 198 posts
We centralized a decentralized version control system.
$2 billion to the first person to draft a decentralised git coin WhitePaper
The goal of the project is to incentivize FOSS development, similar to Bountysource, except without requiring participants to trust a central party. It's pretty cool!
Earlier quoted context omitted.
You can still work with your colleagues by pushing and pulling your own repos without involving GitHub. I think centralised CI is the real problem. I don't have the compute power in my home to run our full test suite, so I can't push with confidence without my CI cluster.
GitLab CI is really sweet, because you deploy your own runners (workers) whereever you want. Downside is, the control is not a standalone CI app but a part of GitLab (or I'm unaware about something). Drone is very promising but last time I've checked the documentation had some holes in it. The website is "coming soon" and IIRC it's like this for quite a long while. I'm unaware about any CIs that are usable with local…
For your local use case GitLab Runner has a local mode exec, although that is currently being reworked https://gitlab.com/gitlab-org/gitlab-runner/issues/2797#note...
We centralized a decentralized version control system.
Git's got two big features over SVN:
1. Automatic, private, per-user branching. Git's even nice enough to keep the private branches out of the main repository, and lets you pretend to be the authoritative repository without creating a branch if you really want to. This is what clone/push/pull actually does, and it's what a distributed VCS really brings to the table. It lets every dev pretend to be the project manager when they're writing their own code.
2. A much improved merging model. The graph model of git is just much better than the linear model of SVN.
The second one is what people thought they wanted when they started using git. The first one is what they didn't know they wanted before they started using git.
Git gets around the problem of "Well, if we do #1, how do we know which repository is authoritative then?" by saying, "We're not solving that problem. This is an exercise for the users that's easily solved by file permissions." So by refusing to solve that (rather hard) problem, the VCS becomes internally decentralized. That doesn't mean you can't or shouldn't centrally manage your repositories or have an authoritative repository. It's just that git itself doesn't care about knowing which repository is authoritative.
Earlier quoted context omitted.
I think you just did.
No. We need a proper whitepaper explaining how to make GitHub decentralized with blockchain tokenization using distributed smart-contracts. ;) (Did I forget any important buzzword?)
deep learning? VR? IoT?
Earlier quoted context omitted.
Issues and other GH infrastructure is arguably a bigger problem. That metadata is locked within the Github silo with no easy way to export it elsewhere.
This is indeed the crux of the problem. I've been thinking about this a lot (and I wouldn't be surprised if it exists already), we need a decentralised method of storing issues and other things inside our git repos.
Every now and then I sketch ideas on the subject, but haven't yet gotten someone to pay me to build it. ;)
Just recently I thought to myself "it has been a long time since I saw the Github Unicorn". As it turns out, I didn't really miss it at all. Regarding the centralized nature of Github: it is the centralized communication that is a problem, not the ability to share code. I can easily send a patch to somebody on my team, but that doesn't help me review a PR, reply to comments, trigger a CI build, or initiate a deploy.…
Further I think these are things that are generally harder to decentralize. I'm not sure how much marginal value there is doing so.
We centralized a decentralized version control system.
The VCS is still decentralized (you can share code with your neighbour or across the world), it's the administration (tickets, PRs, etc) that aren't. I think it'd be fairly straightforward for github or a competitor to store those things in git as plain markdown files, either alongside the main source code, or (as it does with GH Pages) in a separate branch (that has nothing in common with the master branch but it's…
Reposting this ( https://news.ycombinator.com/item?id=16124702 ) as top-level comment, because I think it is worth it: The git-dit project ( https://github.com/neithernut/git-dit ) provides a distributed issue tracking functionality inside git. It does this without cluttering the repository with unneeded files, gives the possibility for having tree-like conversation (including merging conversations), referencing issu…
It is only a matter of time before someone here suggests you use self hosted gitlab/github enterprise. Ain't got time for that.