4 ms·

>Insert remark on why we use a centralized service for a distributed source control system, Because Linus didn't put features into Git that Github solves. Yo

by jasode 9y ago

>Insert remark on why we use a centralized service for a distributed source control system, Because Linus didn't put features into Git that Github solves. You must break apart the different features of Github: #1) communication (issues tracking, bug reports, pull requests, README.MD landing page, etc) #2) hosting disk storage & bandwidth #3) distributed source code merges based on content hashes (SHA1) instead of using centralized locks/unlocks (check in / check out) model of CVS/SVN. Git itself only takes care of #3. Github handles #1 and #2 (and also gets #3 by being built on top of Git). You can't go back in time and wonder if Linus should have addressed #1 and #2 because he wasn't interested in starting a hosting company. Instead, he focused on the data format (Merkle trees, BLOBs, SHA1) and a sync protocol (git pull, etc) for Git. If people wonder why we can't just use email for #1 (communications), you have to see that Github has become a "Schelling Point"[1]. Attempting to use email groups & mailing lists will not prevent the emergence of a Schelling point. Email can be a workflow for existing contributors (e.g. contributors of the Linux kernel source) but it's not convenient for discovery of new repositories (e.g. the web's "landing page" of a repo). As for #2 (hosting), not everybody who wants to share a repository wants to pay $9.99/month VPS or other hosting plan from a web hosting provider. It would also be inconvenient to host it from the home laptop and punch a hole through the ISP router to make it work. Github solves hosting+bandwidth for free for modest non-commercial projects. To restate, Linus' Git is a distributed _protocol_ but Github is a _service_ acting as a platform for the distributed protocol. [1] https://en.wikipedia.org/wiki/Focal_point_(game_theory) https://en.wikipedia.org/wiki/Focal_point_(game_theory)

DaiPlusPlus 9y ago
#1 can be done by creating a separate submodule repo that only stores docs+issues files. It's up to the repo's users to agree on a system by which the files should be organized, but it's doable. I'd propose directories "issues/open", "issues/closed", with each issue filename being "{created:yyyy-MM-dd} - {subject}.md". Symlinks could be used to track ownership/responsibility if each repo contributor has their own directory in the repo too.
- apetresc 9y ago
  That's an awful lot of extra work to insure against maybe 1 hour per year of downtime.
  - sleepybrett 9y ago
    Just because present state is 99.7579% uptime (for the month) doesn't mean it will always be so. You back up your data, why shouldn't you backup your github data?
    - manigandham 9y ago
      Backup is one thing, choosing to run a crappy manual system just in case a vendor goes down is entirely different.
      - DaiPlusPlus 9y ago
        It doesn't have to be a "crappy manual system" - I'm simply suggesting that given that git itself is a damned good distributed versioning database for arbitrary content, then we might as well also use it for distributed issue-tracking. A simple offline-mode browser-based editor that lives in a single HTML file within the repo would provide a nice GUI on top. Hmm, I think I might be on to something... anyone want to start a project?
        jasode 9y ago
        >git itself is a damned good distributed versioning database for arbitrary content, then we might as well also use it for distributed issue-tracking. For what it's worth, it's interesting to see that the Fossil distributed SCM includes an issue tracker but they made a deliberate architecture decision to not propagate the tickets data.[1] They had a chance to make your "distributed-issues-tracking" idea a 1st-class concept in Fossil but decided against it. Also, the issues/tickets is just one example feature. Github will continue to evolve to add more and more sophisticatted SDL/ALM (application lifecycle management) like JIRA and Microsoft Team Foundation Server. Those features are not easy to implement in a peer-2-peer SCM with practical usability. [1] https://fossil-scm.org/xfer/doc/trunk/www/qandc.wiki https://fossil-scm.org/xfer/doc/trunk/www/qandc.wiki

by jasode 9y ago

DaiPlusPlus 9y ago

#1 can be done by creating a separate submodule repo that only stores docs+issues files. It's up to the repo's users to agree on a system by which the files should be organized, but it's doable. I'd propose directories "issues/open", "issues/closed", with each issue filename being "{created:yyyy-MM-dd} - {subject}.md". Symlinks could be used to track ownership/responsibility if each repo contributor has their own directory in the repo too.

apetresc 9y ago
That's an awful lot of extra work to insure against maybe 1 hour per year of downtime.
- sleepybrett 9y ago
  Just because present state is 99.7579% uptime (for the month) doesn't mean it will always be so. You back up your data, why shouldn't you backup your github data?
  - manigandham 9y ago
    Backup is one thing, choosing to run a crappy manual system just in case a vendor goes down is entirely different.
    - DaiPlusPlus 9y ago
      It doesn't have to be a "crappy manual system" - I'm simply suggesting that given that git itself is a damned good distributed versioning database for arbitrary content, then we might as well also use it for distributed issue-tracking. A simple offline-mode browser-based editor that lives in a single HTML file within the repo would provide a nice GUI on top. Hmm, I think I might be on to something... anyone want to start a project?
      - jasode 9y ago
        >git itself is a damned good distributed versioning database for arbitrary content, then we might as well also use it for distributed issue-tracking. For what it's worth, it's interesting to see that the Fossil distributed SCM includes an issue tracker but they made a deliberate architecture decision to not propagate the tickets data.[1] They had a chance to make your "distributed-issues-tracking" idea a 1st-class concept in Fossil but decided against it. Also, the issues/tickets is just one example feature. Github will continue to evolve to add more and more sophisticatted SDL/ALM (application lifecycle management) like JIRA and Microsoft Team Foundation Server. Those features are not easy to implement in a peer-2-peer SCM with practical usability. [1] https://fossil-scm.org/xfer/doc/trunk/www/qandc.wiki https://fossil-scm.org/xfer/doc/trunk/www/qandc.wiki