←back to thread

Mozilla Firefox – Official GitHub repo

(github.com)
848 points thefilmore | 3 comments | 13 May 25 05:23 UTC | HN request time: 0.809s | 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 #
1. guappa ◴[13 May 25 07:55 UTC] No.43970565[source]▶
Have you ever actually used svn?
replies(1): >>43970815 #
2. flohofwoe ◴[13 May 25 08:37 UTC] No.43970815[source]▶
Yes for about 18 years(?) in the context of game development (I don't exactly remember when we had switched from cvs to svn, but it must have been around 2003..2005) in teams up to about 100 people, working copy sizes up to about 150 GB (with most of the data being binary game asset files), and everybody working on trunk (we only used branches for releases which were branched off trunk but never merged back, only cherry-picking bugfixes from the main into release branches as needed).

We used TortoiseSVN as UI which worked well both for devs and non-devs.

With this sort of setup, git would break down completely if it weren't for awkward hacks like git-lfs (which comes with its own share of problems).

replies(1): >>43978342 #
3. nsagent ◴[13 May 25 22:13 UTC] No.43978342[source]▶
Interesting. At game companies I worked at we generally used version control solutions that easily allowed storing code and assets together, such as Perforce and Alienbrain.