←back to thread

Mozilla Firefox – Official GitHub repo

(github.com)
848 points thefilmore | 1 comments | 13 May 25 05:23 UTC | HN request time: 0.236s | source
Show context
bandrami ◴[13 May 25 06:03 UTC] 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 ◴[13 May 25 06:11 UTC] 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 ◴[13 May 25 06:41 UTC] 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 ◴[13 May 25 06:52 UTC] 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 #
baq ◴[13 May 25 06:59 UTC] No.43970262[source]▶
svn was not 'humming' unless you confined yourself to a very narrow set of functionality, e.g. merging was best left to experts.
replies(1): >>43970323 #
1. flohofwoe ◴[13 May 25 07:06 UTC] No.43970323[source]▶
In a centralized version control system with a single history, branching and merging is also much less important.

In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.

When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:

(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.

Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.