10 ms·

What is a fork, and how GitHub changed its meaning

196 points by ddevault 7y ago

shafte 7y ago
I don't know if it's correct to characterize Github's model as a power grab. The design of Github definitely pushes things in a more centralized direction, but I think that approach is superior in many cases and it's not purely for profit. For many projects, having a single "canonical" version is the best experience for both users of the project and developers. Linux is large and important enough that it may make sense to have many different distros running a slightly different set of patches and accept the overhead of managing multiple sources of truth. For smaller projects with more narrow contributor bases, it would be noisy and confusing.
- Retra 7y ago
  Besides that, a de facto centralization is always a much easier pill to swallow then a de jure one.
- wccrawford 7y ago
  Plus, there's absolutely nothing stopping anyone from taking their Git repos and putting them on another Git host. Or hosting their own. Or using multiple hosts. Sure, they're doing things to further their own popularity... But it doesn't appear to be at the expense of anyone else.
- lixtra 7y ago
  > I don't know if it's correct to characterize Github's model as a power grab. The important question would be if Github forks and pull requests are an open protocol or attached to the platform. I’m not aware if I can make a pull request from - say - bitbucket to github. Can I ? Then it’s not a power grab. If not then redefinition of fork/pull request is an extend and extinguish move. Edit: okay, extinguish is too harsh. GitHub doesn’t want to extinguish git.
  - TeMPOraL 7y ago
    Forks and PRs are UI sugar on top of Git operations, so it's technically open. That said, merging in a PR is an operation that touches 2 repos, with different user privileges, so I feel it would be hard (though not impossible) to make the UI work with multiple services, without adding extra cross-service auth headache.
    - the_duke 7y ago
      That's only true for private repos though, for open source repos it would work just fine.
    - saagarjha 7y ago
      > it's technically open Yes, but in a practical sense it ties your operation to GitHub.
  - zdragnar 7y ago
    I don't really see forks or pull requests as being part of the git protocol. They are part of a workflow- no different than, say "git flow" is a workflow, not part of the protocol of how, why and when branching happens. Further, github isn't looking to "extinguish" git in any way. Sure, old workflows (emailing patches?) might not be supported, but again, that's something entirely external to git itself. As these things are all external to git, it makes sense that they're not portable between vendors- they are the vendor's, not git's, features. You're not using them from within git, you're using the vendor's features to interact with git. That's the primary difference between, say, M$FT's EEE of Java or AOL's instant messenger, HTML and other examples.
    - juped 7y ago
      Extinguish doesn't mean to end, it means to end the open standard. Github would be happy if all git use were Github use, and every user locked in to their service brings that day closer.
      - zdragnar 7y ago
- deleted 7y ago
  [deleted]
morpheuskafka 7y ago
I can't imagine doing pull requests over email, which this article notes is an original feature of git. Maybe kernel developers could handle it, but there are a lot of people who don't even know how to send plaintext emails and this would not be conducive to reviewing PRs on mobile. I definitely like the GitHub flow better than SourceHut's.
- Sir_Cmpwn 7y ago
  I shared this video on the Lobsters thread which seems to have been helpful for some: https://yukari.sr.ht/aerc-intro.webm https://yukari.sr.ht/aerc-intro.webm Don't repost this, please, the official aerc announcement is coming in a few weeks. I'm working on making a UI similar to GitHub's for reviewing patches which is built on email underneath, but can be used entirely on the web. The first step of this became available a few weeks ago, and now email threads are being rendered into a review UI which is similar to GitHub's with inline feedback and such: https://lists.sr.ht/~philmd/qemu/patches/5556 https://lists.sr.ht/~philmd/qemu/patches/5556 This page is fairly new and still needs a bit more work towards mobile support, but I hope that gives you some more confidence in the platform. I intend to extend this so that you can also review patches from the web, which will generate emails on the mailing list, and prepare patchsets from the web as well. The end result will be a UI which is remarkably similar to GitHub in terms of usability on the web, but is backed up with distributed technologies and seamlessly integrates with the workflows of devs who would rather use email. On the whole Sourcehut is actually quite a bit better at responsiveness than GitHub, too. Rather than a dedicated and inferior mobile site, almost all sr.ht pages are responsive and equally capable on all form-factors.
  - juped 7y ago
    I love how sourcehut complements git rather than parasitizing on it. That is, I can't fault github's ability to be a dumb remote to publish branches to - but once you use it for that, they have a foot in the door for all the prongs of their proprietary lock-in and what is frankly value-subtract. I'm not worried about that with sourcehut because 1) I don't have to go full sourcehut kool-aid unless I want to (in fact, there's actually too little linkage among the components at present), and 2) if I do, then the kool-aid I've bought into is... a mailing list workflow using decades-old standard technology, where the webapp views are optional.
crazysim 7y ago
It is a curse that GitHub's code search can't code search forked repositories. If there's a really popular fork of a dead repo, it's code is invisible. Though, I have a feeling that is a technical, not business, limitation.
- akerl_ 7y ago
  I suspect it’s largely to avoid ballooning the size of indexed search data they have to store, given the many many forks of popular repos. So a mix of biz/tech reasons, but not really nefarious. That said, given the nature of git, I usually just fall back to clone/grep.
  - crazysim 7y ago
    I just have the SourceGraph extension installed. It's also usable without too. It's a bit more powerful and lets me search forked repositories too on an instance of Sourcegraph on their infrastructure. I still lament not being able to globally (like all of GitHub, not just one repo's forks) search GitHub's forks. It's amazingly useful for finding out approaches to using an API. Sorta like Google Code Search in the old days.
    - sqs 7y ago
      Sourcegraph CEO here. Yes, you can search forked repositories on Sourcegraph with regexp, exact terms, etc. Thanks for mentioning that! Here’s an example of a fork that you can search: https://sourcegraph.com/github.com/uber/gonduit https://sourcegraph.com/github.com/uber/gonduit Just change the repository owner/name in the URL to search any other one.
- deanclatworthy 7y ago
  It's nuts. There's so many old JS/node libraries floating around on github, and it's incredibly difficult and time-consuming to find the one that has been moved forward the most in a fork. There should be a notice on a repo that hasn't had commits or any activity from the author in the last 6 months which links to a better fork view than the one they have.
3JPLW 7y ago
It's a little funny to focus on GitHub's fork/pull-request model if you're trying to critique their centralization and lock-in. Every single successful open source project — on GitHub or not — has a canonical "source" branch and some sort of organization/leadership that decides what goes in. I'd argue that GitHub's behavior here isn't a power grab so much as a reflection of reality. The "real" lock-in is with the discussion model — on both issues and pull requests — and the organizational structure you're able to set up. It's easy to move the source code to another service. Heck, you can even email patches to maintainers of a project on GitHub without creating an account. It's not easy to move historical discussions/reviews or "commit bits"/maintainership roles, and of course you can't participate in reviews of an emailed patch that a maintainer PRs for you unless you create an account.
- Sir_Cmpwn 7y ago
  >Every single successful open source project — on GitHub or not — has a canonical "source" branch This isn't true at all, and I went into detail on this with Linux as an example in the article. Linux is far from the only example, though.
  - 3JPLW 7y ago
    Yes, I did read that. But what is Linus' branch then, and why do folks aim to "upstream" changes to it? I'd argue that the other important Linux sources are _themselves_ cathedrals, each with their own form of centralized leadership — be it an individual or a group (like a distro or company). And these cathedrals happily work together. You can totally have this model with GitHub.
    - Sir_Cmpwn 7y ago
      I see your point. I alluded to a similar idea in an older draft which suggests that bazaar/cathedral style is a spectrum, with most projects not falling entirely within either camp, but clearly having more elements of one model than others. I think that GitHub actively encourages the cathedral model, though. It is possible to use either style on either platform, but the fork/PR model seems to me to be explicitly designed to strongly favor the cathedral model - to the benefit of GitHub's centralization goals, even if obliquely.
loopiv 7y ago
Thanks for this submission. It is the first lucid and intelligently written article in this entire year! Ten years ago it was easier to find content like this one.
dmh2000 7y ago
I'm a casual GitHub user, and for me the fork button enabled me to grab a copy of some other repo, make changes , commit to my github repo without perturbing the main project and still keeping an online history at github. Its a step above just downloading the zip file and below getting commit rights to the original project. If I just made a personal branch, then I would have everything but the online backup because I couldn't commit. One example is used by many online learning companies: they provide some baseline of code for use in a course. you need to get it to use in the lessons (edit: and make changes that you want to save). You can download a zip, clone or fork the repo. zip and clone don't get you the online backup. It would be interesting to see how many people use Github for the reasons cited in the article (using a fork as staging for a pull request) or like I do. As I wrote this, it made me realize I am a parasite on GitHub and the projects I fork, since I rarely contribute back (mainly because I don't have anything useful).
- gowld 7y ago
  You aren't a parasite, you are an intended user like every other. A parasite is one that consumes the host, not one that merely benefits from it.
- johannes1234321 7y ago
  You don't need a fork button for that. git clone ssh://example.com/repo.git [... Edit ...] git push ssh://myserver example.com/myrepo.git master Benefit of the fork button is that GitHub links those repos on their site.
  - zbentley 7y ago
    Ah yes, all of the students in GP's example need merely need to learn how to provision, DNS-associate, and maintain a server, then they can store their Git repositories on it. That will surely not add any undue overhead for them.
    - johannes1234321 7y ago
      There is no need to run a server. This is only about the "fork" button. You could but GitHub.com in the place of example.com. Git hosting existed before GitHub.
dreamcompiler 7y ago
In the absence of external energy inputs, decentralized systems tend toward centralization. I don't much like it, bit it's not really Github's fault that it happens.
robbintt 7y ago
Fork distributes control over history and abstracts permission management away from the traditional git branch pattern so you don't clutter the namespace of the canonical remote but can still offer work. Fork is almost nothing, it's just a useful pattern.
jrandm 7y ago
> On GitHub, a fork refers to a copy of a repository used by a contributor to stage changes they’d like to propose upstream I'm not sure this is accurate and is the crux the argument. IMO a fork on GH refers to a "fresh" (in terms of the tooling around the repo, eg issues/PRs) copy of the repo on another account, which may be used as a branch to push to upstream but may also be the "traditional" fork, the difference is entirely in how the copy is used. If you've got a public "personal branch" with its own associated tooling it doesn't seem like a stretch to call that a fork, whether temporary and intended to be sent back upstream or not, and to me it's a difference without a distinction about why "personal branch" is a better term than "fork." Forking a repo (spinning off a dev section, including CI/CD/issue tracking/management -- a branch implies sharing that infrastructure IMO) isn't the same thing as forking a project (spinning off a competing project). To the cathedral and bazaar points, I don't see how GH affects the development style at all. The only thing that really makes the mailing-list driven Linux dev more decentralized is that it's done via email... yet someone still chooses what goes into releases, maintains & hosts that mailing list/website mirror and could limit access, or the "core" team could simply email each other and lock out any public view. GH can be configured to be just as open (if needing their "fork" model to keep anyone from being able to push over the original hosted copy) or just as closed, depending on how the project is run. The cathedral and bazaar is about project philosophy and management, not the underlying tech, to my reading. Given the disclaimer that the author is building a GH competitor my cynical thought is this is really marketing aimed at the programmer niche; I would have enjoyed it more as a contrast against centralization and the benefits of his (as I understand it) more free/open/decentralized competitor. All that said, I think sr.ht/sourcehut is a cool project and can easily see myself switching to it. How have the ads in 2600 been working?
hyperpallium 7y ago
I really like how github fork can be implemented as new HEAD etc references to the same objects. New commits refer to the original project's objects. i.e. git's content addressing, intended for identical distributed objects also automatically enables de-duplication of identical centralized objects. Regarding the article, it seems to be saying you can't bazazr-fork a project on github. I don't see why not - although the default fork is associated with the forked project, why can't you start a new project, using a clone of the forked project?
- Sir_Cmpwn 7y ago
  >I really like how github fork can be implemented as new HEAD etc references to the same objects. New commits refer to the original project's objects. This can be done (more effectively, actually) without the user's explicit involvement in the fork process. You can dedupe blobs across the entire platform on git push. >Regarding the article, it seems to be saying you can't bazazr-fork a project on github I'm not saying you can't (I thought that was clear enough), but that GitHub is designed to encourage you to use a different approach.
k__ 7y ago
I don't understand. I forked quite some repos on GitHub, because they weren't maintained anymore or I needed some feature the maintainer wouldn't implement.

196 points by ddevault 7y ago

I don't know if it's correct to characterize Github's model as a power grab. The design of Github definitely pushes things in a more centralized direction, but I think that approach is superior in many cases and it's not purely for profit. For many projects, having a single "canonical" version is the best experience for both users of the project and developers. Linux is large and important enough that it may make sense to have many different distros running a slightly different set of patches and accept the overhead of managing multiple sources of truth. For smaller projects with more narrow contributor bases, it would be noisy and confusing.

Retra 7y ago
Besides that, a de facto centralization is always a much easier pill to swallow then a de jure one.
wccrawford 7y ago
Plus, there's absolutely nothing stopping anyone from taking their Git repos and putting them on another Git host. Or hosting their own. Or using multiple hosts. Sure, they're doing things to further their own popularity... But it doesn't appear to be at the expense of anyone else.
lixtra 7y ago
> I don't know if it's correct to characterize Github's model as a power grab. The important question would be if Github forks and pull requests are an open protocol or attached to the platform. I’m not aware if I can make a pull request from - say - bitbucket to github. Can I ? Then it’s not a power grab. If not then redefinition of fork/pull request is an extend and extinguish move. Edit: okay, extinguish is too harsh. GitHub doesn’t want to extinguish git.
- TeMPOraL 7y ago
  Forks and PRs are UI sugar on top of Git operations, so it's technically open. That said, merging in a PR is an operation that touches 2 repos, with different user privileges, so I feel it would be hard (though not impossible) to make the UI work with multiple services, without adding extra cross-service auth headache.
  - the_duke 7y ago
    That's only true for private repos though, for open source repos it would work just fine.
  - saagarjha 7y ago
    > it's technically open Yes, but in a practical sense it ties your operation to GitHub.
- zdragnar 7y ago
  I don't really see forks or pull requests as being part of the git protocol. They are part of a workflow- no different than, say "git flow" is a workflow, not part of the protocol of how, why and when branching happens. Further, github isn't looking to "extinguish" git in any way. Sure, old workflows (emailing patches?) might not be supported, but again, that's something entirely external to git itself. As these things are all external to git, it makes sense that they're not portable between vendors- they are the vendor's, not git's, features. You're not using them from within git, you're using the vendor's features to interact with git. That's the primary difference between, say, M$FT's EEE of Java or AOL's instant messenger, HTML and other examples.
  - juped 7y ago
    Extinguish doesn't mean to end, it means to end the open standard. Github would be happy if all git use were Github use, and every user locked in to their service brings that day closer.
    - zdragnar 7y ago
deleted 7y ago
[deleted]

morpheuskafka 7y ago

I can't imagine doing pull requests over email, which this article notes is an original feature of git. Maybe kernel developers could handle it, but there are a lot of people who don't even know how to send plaintext emails and this would not be conducive to reviewing PRs on mobile. I definitely like the GitHub flow better than SourceHut's.

Sir_Cmpwn 7y ago
I shared this video on the Lobsters thread which seems to have been helpful for some: https://yukari.sr.ht/aerc-intro.webm https://yukari.sr.ht/aerc-intro.webm Don't repost this, please, the official aerc announcement is coming in a few weeks. I'm working on making a UI similar to GitHub's for reviewing patches which is built on email underneath, but can be used entirely on the web. The first step of this became available a few weeks ago, and now email threads are being rendered into a review UI which is similar to GitHub's with inline feedback and such: https://lists.sr.ht/~philmd/qemu/patches/5556 https://lists.sr.ht/~philmd/qemu/patches/5556 This page is fairly new and still needs a bit more work towards mobile support, but I hope that gives you some more confidence in the platform. I intend to extend this so that you can also review patches from the web, which will generate emails on the mailing list, and prepare patchsets from the web as well. The end result will be a UI which is remarkably similar to GitHub in terms of usability on the web, but is backed up with distributed technologies and seamlessly integrates with the workflows of devs who would rather use email. On the whole Sourcehut is actually quite a bit better at responsiveness than GitHub, too. Rather than a dedicated and inferior mobile site, almost all sr.ht pages are responsive and equally capable on all form-factors.
- juped 7y ago
  I love how sourcehut complements git rather than parasitizing on it. That is, I can't fault github's ability to be a dumb remote to publish branches to - but once you use it for that, they have a foot in the door for all the prongs of their proprietary lock-in and what is frankly value-subtract. I'm not worried about that with sourcehut because 1) I don't have to go full sourcehut kool-aid unless I want to (in fact, there's actually too little linkage among the components at present), and 2) if I do, then the kool-aid I've bought into is... a mailing list workflow using decades-old standard technology, where the webapp views are optional.

crazysim 7y ago

It is a curse that GitHub's code search can't code search forked repositories. If there's a really popular fork of a dead repo, it's code is invisible. Though, I have a feeling that is a technical, not business, limitation.

akerl_ 7y ago
I suspect it’s largely to avoid ballooning the size of indexed search data they have to store, given the many many forks of popular repos. So a mix of biz/tech reasons, but not really nefarious. That said, given the nature of git, I usually just fall back to clone/grep.
- crazysim 7y ago
  I just have the SourceGraph extension installed. It's also usable without too. It's a bit more powerful and lets me search forked repositories too on an instance of Sourcegraph on their infrastructure. I still lament not being able to globally (like all of GitHub, not just one repo's forks) search GitHub's forks. It's amazingly useful for finding out approaches to using an API. Sorta like Google Code Search in the old days.
  - sqs 7y ago
    Sourcegraph CEO here. Yes, you can search forked repositories on Sourcegraph with regexp, exact terms, etc. Thanks for mentioning that! Here’s an example of a fork that you can search: https://sourcegraph.com/github.com/uber/gonduit https://sourcegraph.com/github.com/uber/gonduit Just change the repository owner/name in the URL to search any other one.
deanclatworthy 7y ago
It's nuts. There's so many old JS/node libraries floating around on github, and it's incredibly difficult and time-consuming to find the one that has been moved forward the most in a fork. There should be a notice on a repo that hasn't had commits or any activity from the author in the last 6 months which links to a better fork view than the one they have.

3JPLW 7y ago

It's a little funny to focus on GitHub's fork/pull-request model if you're trying to critique their centralization and lock-in. Every single successful open source project — on GitHub or not — has a canonical "source" branch and some sort of organization/leadership that decides what goes in. I'd argue that GitHub's behavior here isn't a power grab so much as a reflection of reality. The "real" lock-in is with the discussion model — on both issues and pull requests — and the organizational structure you're able to set up. It's easy to move the source code to another service. Heck, you can even email patches to maintainers of a project on GitHub without creating an account. It's not easy to move historical discussions/reviews or "commit bits"/maintainership roles, and of course you can't participate in reviews of an emailed patch that a maintainer PRs for you unless you create an account.

Sir_Cmpwn 7y ago
>Every single successful open source project — on GitHub or not — has a canonical "source" branch This isn't true at all, and I went into detail on this with Linux as an example in the article. Linux is far from the only example, though.
- 3JPLW 7y ago
  Yes, I did read that. But what is Linus' branch then, and why do folks aim to "upstream" changes to it? I'd argue that the other important Linux sources are _themselves_ cathedrals, each with their own form of centralized leadership — be it an individual or a group (like a distro or company). And these cathedrals happily work together. You can totally have this model with GitHub.
  - Sir_Cmpwn 7y ago
    I see your point. I alluded to a similar idea in an older draft which suggests that bazaar/cathedral style is a spectrum, with most projects not falling entirely within either camp, but clearly having more elements of one model than others. I think that GitHub actively encourages the cathedral model, though. It is possible to use either style on either platform, but the fork/PR model seems to me to be explicitly designed to strongly favor the cathedral model - to the benefit of GitHub's centralization goals, even if obliquely.

loopiv 7y ago

Thanks for this submission. It is the first lucid and intelligently written article in this entire year! Ten years ago it was easier to find content like this one.

dmh2000 7y ago

I'm a casual GitHub user, and for me the fork button enabled me to grab a copy of some other repo, make changes , commit to my github repo without perturbing the main project and still keeping an online history at github. Its a step above just downloading the zip file and below getting commit rights to the original project. If I just made a personal branch, then I would have everything but the online backup because I couldn't commit. One example is used by many online learning companies: they provide some baseline of code for use in a course. you need to get it to use in the lessons (edit: and make changes that you want to save). You can download a zip, clone or fork the repo. zip and clone don't get you the online backup. It would be interesting to see how many people use Github for the reasons cited in the article (using a fork as staging for a pull request) or like I do. As I wrote this, it made me realize I am a parasite on GitHub and the projects I fork, since I rarely contribute back (mainly because I don't have anything useful).

gowld 7y ago
You aren't a parasite, you are an intended user like every other. A parasite is one that consumes the host, not one that merely benefits from it.
johannes1234321 7y ago
You don't need a fork button for that. git clone ssh://example.com/repo.git [... Edit ...] git push ssh://myserver example.com/myrepo.git master Benefit of the fork button is that GitHub links those repos on their site.
- zbentley 7y ago
  Ah yes, all of the students in GP's example need merely need to learn how to provision, DNS-associate, and maintain a server, then they can store their Git repositories on it. That will surely not add any undue overhead for them.
  - johannes1234321 7y ago
    There is no need to run a server. This is only about the "fork" button. You could but GitHub.com in the place of example.com. Git hosting existed before GitHub.

dreamcompiler 7y ago

In the absence of external energy inputs, decentralized systems tend toward centralization. I don't much like it, bit it's not really Github's fault that it happens.

robbintt 7y ago

Fork distributes control over history and abstracts permission management away from the traditional git branch pattern so you don't clutter the namespace of the canonical remote but can still offer work. Fork is almost nothing, it's just a useful pattern.

jrandm 7y ago

> On GitHub, a fork refers to a copy of a repository used by a contributor to stage changes they’d like to propose upstream I'm not sure this is accurate and is the crux the argument. IMO a fork on GH refers to a "fresh" (in terms of the tooling around the repo, eg issues/PRs) copy of the repo on another account, which may be used as a branch to push to upstream but may also be the "traditional" fork, the difference is entirely in how the copy is used. If you've got a public "personal branch" with its own associated tooling it doesn't seem like a stretch to call that a fork, whether temporary and intended to be sent back upstream or not, and to me it's a difference without a distinction about why "personal branch" is a better term than "fork." Forking a repo (spinning off a dev section, including CI/CD/issue tracking/management -- a branch implies sharing that infrastructure IMO) isn't the same thing as forking a project (spinning off a competing project). To the cathedral and bazaar points, I don't see how GH affects the development style at all. The only thing that really makes the mailing-list driven Linux dev more decentralized is that it's done via email... yet someone still chooses what goes into releases, maintains & hosts that mailing list/website mirror and could limit access, or the "core" team could simply email each other and lock out any public view. GH can be configured to be just as open (if needing their "fork" model to keep anyone from being able to push over the original hosted copy) or just as closed, depending on how the project is run. The cathedral and bazaar is about project philosophy and management, not the underlying tech, to my reading. Given the disclaimer that the author is building a GH competitor my cynical thought is this is really marketing aimed at the programmer niche; I would have enjoyed it more as a contrast against centralization and the benefits of his (as I understand it) more free/open/decentralized competitor. All that said, I think sr.ht/sourcehut is a cool project and can easily see myself switching to it. How have the ads in 2600 been working?

hyperpallium 7y ago

I really like how github fork can be implemented as new HEAD etc references to the same objects. New commits refer to the original project's objects. i.e. git's content addressing, intended for identical distributed objects also automatically enables de-duplication of identical centralized objects. Regarding the article, it seems to be saying you can't bazazr-fork a project on github. I don't see why not - although the default fork is associated with the forked project, why can't you start a new project, using a clone of the forked project?

Sir_Cmpwn 7y ago
>I really like how github fork can be implemented as new HEAD etc references to the same objects. New commits refer to the original project's objects. This can be done (more effectively, actually) without the user's explicit involvement in the fork process. You can dedupe blobs across the entire platform on git push. >Regarding the article, it seems to be saying you can't bazazr-fork a project on github I'm not saying you can't (I thought that was clear enough), but that GitHub is designed to encourage you to use a different approach.

k__ 7y ago

I don't understand. I forked quite some repos on GitHub, because they weren't maintained anymore or I needed some feature the maintainer wouldn't implement.