←back to thread

848 points thefilmore | 1 comments | | HN request time: 0.33s | 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 #
rablackburn ◴[] No.43970301[source]
>> I would love a good issue tracking system that is done entirely inside git

You might like git-bug:

https://github.com/git-bug/git-bug

replies(1): >>43971681 #
sublinear ◴[] No.43971681[source]
Why bury this in the documentation if it's the sole feature its users would care about? https://github.com/git-bug/git-bug/blob/master/doc/design/da...

This should be one of the very first links in the readme.

replies(2): >>43980638 #>>43980718 #
1. sudoforge ◴[] No.43980718[source]
hey there! i maintain git-bug, and recently trimmed down the README, which was, in my opinion, a bit too dense prior to this recent change (https://github.com/git-bug/git-bug/commit/96c7a111a3cb075b5c...).

i rewrote the README with the goal of providing a clear overview of git-bug's features, and why you might want to use it, and ensuring that for those who are more technically inclined, things like the data model, internal architecture, and more were easy to find under the documentation folder (whether you're browsing through the files directly, or landing on //doc:README.md, which links to the files and folders under //doc.

if you think that there is information missing from the README, or hard to find in the repository (either by browsing through it, or clicking the rather prominent links from the main README), i'd welcome any suggestions in the form of a PR.