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.
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.
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.
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.
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.
> 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?
I agree that the GUI situation is a glass-half-full sort of thing, I'm just saying it needs that as a priority if they want any network effect.
> The patch command [0] has a propose subcommand that describes what you're talking about.
Yeah but in the tutorial it says it will fail to work if you are on a different branch from master - I took it to mean that the patch command can only target the same branch it was generated on. If that's the case, obviously the maintainer can then do the manual merge-and-delete routine; I'm just saying that on github it's a one-click operation.
Your sister comment had another project to share based on IPFS: https://radicle.xyz/
One thing that seems clear is that there needs to be a standard interchangeable format for storing PRs and issues, so that it's not just the point of origin that's decentralized, but the data itself (in case the maintainers vanish).
I'm not really sure how to go about that sort of thing either myself or as a community effort but I'd appreciate any advice from the HN community.
> One thing that seems clear is that there needs to be a standard interchangeable format for storing PRs and issues, so that it's not just the point of origin that's decentralized, but the data itself (in case the maintainers vanish).
I use Artemis for issue tracking, and that uses maildir (a widely supported standard). I compose issues with Emacs message-mode and render them to HTML using mhonarc.
> anybody can push to anybody else's git repository. [...]
The nomenclature is to treat the ssb remote as the "true" remote, and work off of a branch called @your-username/master as your own master, emulating a forked repo. This seems to work well: the SSB network thrives off of being a group of kind, respectful folks who don't push to each other's master branch. :)
Uh, thanks but no thanks. I thought we had learnt that the honor system does not scale.
> decentralization was a secondary effect of the workflow Linus wanted to achieve.
Linus didn't want to achieve a change in workflow of kernel development, he just made a tool to make which would ease the pain, Linux development was decentralized since forever.
What I said is that the design of git was driven by the requirements of async workflow (“easing the pain”, in your words) more than decentralization as a philosophical objective. I think we saying the same thing with different words.
I still wonder if Larry McVoy feels sore that git basically destroyed BitKeeper and became what it did. “It could have been me” and all that...
