{"action":"created","issue":{"url":"https://api.github.com/repos/cjb/GitTorrent/issues/20","labels_url":"https://api.github.com/repos/cjb/GitTorrent/issues/20/labels{/name}","comments_url":"https://api.github.com/repos/cjb/GitTorrent/issues/20/comments","events_url":"https://api.github.com/repos/cjb/GitTorrent/issues/20/events","html_url":"https://github.com/cjb/GitTorrent/issues/20","id":83127058,"number":20,"title":"No Pull Requests in the Protocol","user":{"login":"alexanderkyte","id":700530,"avatar_url":"https://avatars.githubusercontent.com/u/700530?v=3","gravatar_id":"","url":"https://api.github.com/users/alexanderkyte","html_url":"https://github.com/alexanderkyte","followers_url":"https://api.github.com/users/alexanderkyte/followers","following_url":"https://api.github.com/users/alexanderkyte/following{/other_user}","gists_url":"https://api.github.com/users/alexanderkyte/gists{/gist_id}","starred_url":"https://api.github.com/users/alexanderkyte/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alexanderkyte/subscriptions","organizations_url":"https://api.github.com/users/alexanderkyte/orgs","repos_url":"https://api.github.com/users/alexanderkyte/repos","events_url":"https://api.github.com/users/alexanderkyte/events{/privacy}","received_events_url":"https://api.github.com/users/alexanderkyte/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":21,"created_at":"2015-05-31T16:24:16Z","updated_at":"2015-06-07T21:01:33Z","closed_at":null,"body":"People use public version control in general because it offers free public hosting, but they use github specifically because of how easy it is to fork a new repo and because of how nice the pull request workflow is. Git will never be distributed in any useful sense as long as the entire project's merge process and history are centralized and without an easy export format.\r\n\r\nI'd like to consider using git itself to track this kind of thing, kind of like a \"side chain\" running on top of git. In another branch for a given repo, the state of bugs and PRs could be tracked. "},"comment":{"url":"https://api.github.com/repos/cjb/GitTorrent/issues/comments/109799437","html_url":"https://github.com/cjb/GitTorrent/issues/20#issuecomment-109799437","issue_url":"https://api.github.com/repos/cjb/GitTorrent/issues/20","id":109799437,"user":{"login":"alexanderkyte","id":700530,"avatar_url":"https://avatars.githubusercontent.com/u/700530?v=3","gravatar_id":"","url":"https://api.github.com/users/alexanderkyte","html_url":"https://github.com/alexanderkyte","followers_url":"https://api.github.com/users/alexanderkyte/followers","following_url":"https://api.github.com/users/alexanderkyte/following{/other_user}","gists_url":"https://api.github.com/users/alexanderkyte/gists{/gist_id}","starred_url":"https://api.github.com/users/alexanderkyte/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alexanderkyte/subscriptions","organizations_url":"https://api.github.com/users/alexanderkyte/orgs","repos_url":"https://api.github.com/users/alexanderkyte/repos","events_url":"https://api.github.com/users/alexanderkyte/events{/privacy}","received_events_url":"https://api.github.com/users/alexanderkyte/received_events","type":"User","site_admin":false},"created_at":"2015-06-07T21:01:33Z","updated_at":"2015-06-07T21:01:33Z","body":"One of the problems with software development in general is the distribution of progress. People file bugs in trackers that aren't directly linked to the source control, or their documentation has nothing to validate that the arguments documented are even arguments to the function, or git blame only returns \"fixed that file bug\" as the commit message for a given commit with no idea which bug it is. \r\n\r\nI'm against storing this in a format that isn't strongly associated with the repository. It's all good and well to find the most clever, lowest-bandwidth, most secure way to make PRs, but that won't help you unless it's easier for people to use it than for them not to use it. \r\n\r\nI think that having this PR/bug information in the source control itself is the best way to go. Let's say someone googles some FFI library that has a horrific bug in it, and they wait around for a fix. They return much later and see that it was fixed months ago. When you're at commit T, you want to be able to know if issue Y still holds at that commit. This repository metadata is as much part of the source control as the comments are.\r\n\r\nYou can track this in a separate database(consistency is hard guys) or you can put it right in the git blockchain."}}