3 ms·
ok, let's try describe a simple scenario. There's a hundreds of developers in your git, thousands watching it, now there's an security issue. You want to includ
by est 8y ago
ok, let's try describe a simple scenario. There's a hundreds of developers in your git, thousands watching it, now there's an security issue. You want to include a few trusted ones to discuss a patch, how do you proceed? Especially how do you move around the disccusion content around with your git repo?
- zAy0LfpBZLC8mAC 8y agoNow, there are many ways to implement a solution for this, and I personally would probably prefer simple patches in plain text emails, unless it's a really complicated issue with a massive patch. But in any case, your mistake seems to be in thinking in terms of one repo. You don't need that. Every developer can have their own repo published somewhere. Or even more than one. And for the probably simplest solution for limited access, you just add http authentication in front of that repo and then send the URI including the credentials via email. Is that the perfect solution? Maybe not. But the point is that you don't need a centralized gatekeeper. If you don't like email, you can build new communication protocols that use DNS names for identity. Or you could integrate email more with git so git automatically imports machine-readable pull requests you receive via email. Or whatever. There are endless possibilities that can use DNS names for federation of independently hosted repositories and issues trackers and whatnot. And there exist many implementations of ideas as well. You also could use OpenID for federated authentication.
- est 8y agoI think it comes down to two scopes of the .git: 1. preserve source code change history 2. preserve history of how the project evolves. Github serves the #2 well but in an centralized way. But #2 is kinda essential these days. People need to know how the code changed but also WHY.