6 ms·

Yes, but that's not a new concern - to some, GitHub has always represented an anathema to what git was supposed to be and bring. Centralization at a proprietary

by sho_hn 8y ago

Yes, but that's not a new concern - to some, GitHub has always represented an anathema to what git was supposed to be and bring. Centralization at a proprietary vendor, instead of open systems interacting. Then locking people in further by network effect and adding centralized products around git. That it's become so popular many people equate GitHub with git adds insult to injury. I completely understand why this all happened (centralization is just so easy and convenient; federation is hard), and it was probably inevitable in its timeframe, but I also wish it wasn't so. It's not quite what we imagined when we made the leap to dscms in the early aughts. All the good stuff is still in there, though, and it's still as possible as ever to do different things, so it's not a bleak situation.

beenBoutIT 8y ago
*When the tech giant is Microsoft.
tedivm 8y ago
When Linus introduced git he didn't seem to care at all about decentralizing from a political standpoint, just from a "I can work on this from my laptop without an internet connection" point of view.
- toyg 8y ago
  That's the thing - git was fundamentally a tool borne with an asynchronous workflow in mind: I work on X, Alice works on Y, Bob works on Z, and the eventual merging (which might happen days or weeks later) should be as simple as possible - without worrying about who checked out what. Git was dropped in the "distributed VCS" bucket, but decentralization was a secondary effect of the workflow Linus wanted to achieve. GitHub then took the server-side bits of git, and effectively built a web-based interface with social features on top. Git itself is still very much a decentralized tool (just add a new remote and off you go), only the social GUI is centralized. It would be cool if somebody could build "Github over P2P" (I guess with a bit of blockchain, because hype). At that point the entire stack would be fully decentralized.
  - soulofmischief 8y ago
    A git service built on IPFS or something similar would be wicked. It does take quite a bit of engineering (money) to compete with the big boys, however.
    - chupasaurus 8y ago
      The first project provided by DDG to me was Radicle[https://radicle.xyz/ https://radicle.xyz/]
      - soulofmischief 8y ago
        rad project allows you to create, checkout, manage, and publish a project, comprised of issues, patch proposals, and a git repo. Well hot dog. And it uses LISP for scripting? Nice. Interesting approach to saving state, too.: One only needs the address of the latest input, the "head", to be able to recover the whole log. The owner of a machine uses an IPNS link to point to the head of the list, and the name of this link is then the name of the machine also. Thanks for sharing that. Definitely going to give it a whirl this weekend.
        toyg 8y ago
        It looks the business but it lacks the single most important feature for popularity: a GUI. GitHub made Git dominant by building a friendly GUI on top of it. Before, it was just another player in a relatively crowded field of CLI DVCSs. Obviously it is not essential to get stuff done, but anything with any ambition of generating network effects definitely needs a GUI. The other thing that seems to be lacking, from a quick reading of the docs, is a way to generate pull requests (or "patches" in Rad terms) from a branch, and then merge them on another branch. Obviously you can do it manually in git, but GH is definitely a superior experience.
        soulofmischief 7y ago
        > It looks the business but it lacks the single most important feature for popularity: a GUI. It's a matter of perspective. My first thought when reading the docs was, "All someone needs to do is slap a GUI on this baby. Good thing the designers made a simple CLI that it could interface with." They've already done most of the heavy lifting. At this point a GUI is trivial to add. "Terminal–first" doesn't imply "terminal-only". In fact, quite the opposite. I wouldn't be so quick to assume that they don't envision a GUI at some point-- Why not contribute to the project and get the ball rolling? The patch command [0] has a propose subcommand that describes what you're talking about. It generates a patch from a commit (on any branch, I presume). This can be applied however you see fit. And the checkout subcommand even lets you generate branches from patches similar to GH. What seems to be missing? [0] https://radicle.xyz/docs/#rad-cli-reference https://radicle.xyz/docs/#rad-cli-reference
arugulum 8y ago
I have the opposite view: the success of GitHub and the growth of code being open by default with everything running through git has probably brought more people into the git ecosystem than would have otherwise. I primarily use GitHub, but whenever I need something that I need to run myself I know I can fairly seamlessly switch over to something like GitLab. For example, if GitHub ever started using a very proprietary application, I would just switch over to using regular git, and I'm guessing many others would too.
- jeena 8y ago
  I don't believe you would. It's more probable that you'd install that proprietary application to get the features which standard git lacks at that time.
- keytarsolo 8y ago
  I am with you on this one. I use GitHub to share code, and participate in projects. I use my own GitBucket instance for anything purely personal that I don't want to lose, but don't want to make nice or document and then at work we use GitLab. I'm all in on git in a way that I might not have been without GitHub making it so huge. Without GitHub, we'd probably all be using git at home but SVN at the office.
soulofmischief 8y ago
I just wish a PR and issue tracking system with pluggable credentials had been simultaneously developed and implemented alongside git, so that I could migrate my issue and PR history, or plug them in to multiple hosts. I prefer Gitlab for a multitude of reasons but since all the action takes place on Github, my Gitlab account just serves as a repo mirror.
- chriswarbo 7y ago
  Git has always had integration with email, which makes it compatible with a vast amount of existing servers, clients, credential systems, Web UIs, scripting languages, etc. As an example I think SourceHut is mostly based around email (which it provides a Web UI for) https://sourcehut.org https://sourcehut.org

by sho_hn 8y ago

beenBoutIT 8y ago

*When the tech giant is Microsoft.

tedivm 8y ago

When Linus introduced git he didn't seem to care at all about decentralizing from a political standpoint, just from a "I can work on this from my laptop without an internet connection" point of view.

toyg 8y ago
That's the thing - git was fundamentally a tool borne with an asynchronous workflow in mind: I work on X, Alice works on Y, Bob works on Z, and the eventual merging (which might happen days or weeks later) should be as simple as possible - without worrying about who checked out what. Git was dropped in the "distributed VCS" bucket, but decentralization was a secondary effect of the workflow Linus wanted to achieve. GitHub then took the server-side bits of git, and effectively built a web-based interface with social features on top. Git itself is still very much a decentralized tool (just add a new remote and off you go), only the social GUI is centralized. It would be cool if somebody could build "Github over P2P" (I guess with a bit of blockchain, because hype). At that point the entire stack would be fully decentralized.
- soulofmischief 8y ago
  A git service built on IPFS or something similar would be wicked. It does take quite a bit of engineering (money) to compete with the big boys, however.
  - chupasaurus 8y ago
    The first project provided by DDG to me was Radicle[https://radicle.xyz/ https://radicle.xyz/]
    - soulofmischief 8y ago
      rad project allows you to create, checkout, manage, and publish a project, comprised of issues, patch proposals, and a git repo. Well hot dog. And it uses LISP for scripting? Nice. Interesting approach to saving state, too.: One only needs the address of the latest input, the "head", to be able to recover the whole log. The owner of a machine uses an IPNS link to point to the head of the list, and the name of this link is then the name of the machine also. Thanks for sharing that. Definitely going to give it a whirl this weekend.
      - toyg 8y ago
        It looks the business but it lacks the single most important feature for popularity: a GUI. GitHub made Git dominant by building a friendly GUI on top of it. Before, it was just another player in a relatively crowded field of CLI DVCSs. Obviously it is not essential to get stuff done, but anything with any ambition of generating network effects definitely needs a GUI. The other thing that seems to be lacking, from a quick reading of the docs, is a way to generate pull requests (or "patches" in Rad terms) from a branch, and then merge them on another branch. Obviously you can do it manually in git, but GH is definitely a superior experience.
        soulofmischief 7y ago
        > It looks the business but it lacks the single most important feature for popularity: a GUI. It's a matter of perspective. My first thought when reading the docs was, "All someone needs to do is slap a GUI on this baby. Good thing the designers made a simple CLI that it could interface with." They've already done most of the heavy lifting. At this point a GUI is trivial to add. "Terminal–first" doesn't imply "terminal-only". In fact, quite the opposite. I wouldn't be so quick to assume that they don't envision a GUI at some point-- Why not contribute to the project and get the ball rolling? The patch command [0] has a propose subcommand that describes what you're talking about. It generates a patch from a commit (on any branch, I presume). This can be applied however you see fit. And the checkout subcommand even lets you generate branches from patches similar to GH. What seems to be missing? [0] https://radicle.xyz/docs/#rad-cli-reference https://radicle.xyz/docs/#rad-cli-reference

arugulum 8y ago

I have the opposite view: the success of GitHub and the growth of code being open by default with everything running through git has probably brought more people into the git ecosystem than would have otherwise. I primarily use GitHub, but whenever I need something that I need to run myself I know I can fairly seamlessly switch over to something like GitLab. For example, if GitHub ever started using a very proprietary application, I would just switch over to using regular git, and I'm guessing many others would too.

jeena 8y ago
I don't believe you would. It's more probable that you'd install that proprietary application to get the features which standard git lacks at that time.
keytarsolo 8y ago
I am with you on this one. I use GitHub to share code, and participate in projects. I use my own GitBucket instance for anything purely personal that I don't want to lose, but don't want to make nice or document and then at work we use GitLab. I'm all in on git in a way that I might not have been without GitHub making it so huge. Without GitHub, we'd probably all be using git at home but SVN at the office.

soulofmischief 8y ago

I just wish a PR and issue tracking system with pluggable credentials had been simultaneously developed and implemented alongside git, so that I could migrate my issue and PR history, or plug them in to multiple hosts. I prefer Gitlab for a multitude of reasons but since all the action takes place on Github, my Gitlab account just serves as a repo mirror.

chriswarbo 7y ago
Git has always had integration with email, which makes it compatible with a vast amount of existing servers, clients, credential systems, Web UIs, scripting languages, etc. As an example I think SourceHut is mostly based around email (which it provides a Web UI for) https://sourcehut.org https://sourcehut.org