(Replying to PARENT post)
(Replying to PARENT post)
Yes, git still works. But we don't just rely on the features git provides.
(Replying to PARENT post)
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.
(Replying to PARENT post)
Decentralization just doesn't work too well in practice for whatever reason. Everyone is behind a NAT/firewall, everyone has low computing power, its hard to regulate, etc. This all leads to a centralized solution being easier.
I think the current best thing we have is centralized but open source and encrypted, which gets an "okay"/10 from me.
(Replying to PARENT post)
(Replying to PARENT post)
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.
(Replying to PARENT post)
The point of git is that everyone can keep working right now and can push later without things getting very messy.
(Replying to PARENT post)
edit: Oh jesus christ, there's a fucking tech company called Square Wheel. Kill me now.
(Replying to PARENT post)
I canβt push changes to the decentralized Git protocol, only to a (centralized) server instance.
(Replying to PARENT post)
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 still in the same repo).
Similar (maybe) is ADR (http://thinkrelevance.com/blog/2011/11/15/documenting-archit...), storing architectural decisions into numbered files in git. See also: https://github.com/npryce/adr-tools
(Replying to PARENT post)