←back to thread

848 points thefilmore | 1 comments | | HN request time: 1.841s | source
Show context
bandrami ◴[] No.43969975[source]
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
replies(29): >>43969999 #>>43970002 #>>43970008 #>>43970018 #>>43970019 #>>43970028 #>>43970031 #>>43970032 #>>43970036 #>>43970037 #>>43970142 #>>43970154 #>>43970198 #>>43970282 #>>43970314 #>>43970343 #>>43970418 #>>43970419 #>>43970431 #>>43970434 #>>43970451 #>>43970472 #>>43970541 #>>43970904 #>>43971268 #>>43971299 #>>43971387 #>>43971586 #>>43988717 #
SCdF ◴[] No.43970018[source]
I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back.

Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)

replies(9): >>43970039 #>>43970120 #>>43970143 #>>43970151 #>>43970180 #>>43970299 #>>43970301 #>>43970480 #>>43970514 #
sshine ◴[] No.43970143[source]
> if github goes down you could still generate patches and email them around, and then push back to github when it's back.

You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository.

> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)

Radicle offers one. CLI-based, too.

replies(4): >>43970191 #>>43970214 #>>43970429 #>>43970525 #
flohofwoe ◴[] No.43970214[source]
> They learn a set of narrow workflows and never explore beyond.

And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem.

I don't need to know how a filesystem works internally to be able to use it.

And having a centralized store and history helps a lot to keep a version control system conceptually simple.

replies(5): >>43970218 #>>43970262 #>>43970270 #>>43970425 #>>43970565 #