←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.001s | 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 #
vishnugupta ◴[13 May 25 07:25 UTC] No.43970425[source]▶
svn was a nightmare when it came to handling conflicts. So at least for me, humming in the background wasn’t the term used for it at work.
replies(1): >>43970929 #
1. flohofwoe ◴[13 May 25 08:55 UTC] No.43970929[source]▶
This was only for true before svn 1.5 (before it had 'merge tracking'). Also, branching and merging by far wasn't as essential in svn as it is in a decentralized version control system like git. In a centralized version control system it works perfectly well to do all development in the main branch, and only branch off dead-end 'release branches' which are never merged back.

Tbh, I really wonder where the bad reputation of svn is coming from. Git does some things better, especially for 'programmer-centric teams'. But it also does many things worse, especially in projects where the majority of data is large binary files (like in game development) - and it's not like git is any good either when it comes to merging binary data.