What is a fork, and how GitHub changed its meaning

https://drewdevault.com/2019/05/24/What-is-a-fork.html

by ddevault • 7 years ago

196 76 7 years ago

shafte• 7 years 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• 7 years ago

Besides that, a de facto centralization is always a much easier pill to swallow then a de jure one.

wccrawford• 7 years 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.

lixtra2• 7 years 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• 7 years 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.

zdragnar2• 7 years 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.

usrusr2• 7 years ago

The important question would be if Github forks and pull requests are an open protocol or attached to the platform.

Attached to the platform, but open. You could do all the work on your feature branch somewhere else, say, your company's gitlab installation, then when it's done, push the branch into your github "fork" and and create a pull request there. I really don't know on which side of an openness line that would fall, you can easily define the line around it either way.

theamk• 7 years ago

It’s all git, so you can totally do all the development in gitlab, and only touch github when you are ready to make a pull request.

You’d have to run half a dozen commands, including adding new remote and running “hub fork”, but it would likely still be faster than sending an email.

morpheuskafka• 7 years 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_Cmpwn7• 7 years ago

I shared this video on the Lobsters thread which seems to have been helpful for some:

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

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.

juped2• 7 years 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.

jasonhansel• 7 years ago

Whoa! This is a great idea. Looking forward to the "real" post; I've also done some work on implementing distributed systems over email, so I'll be sure to give this a look.

instantwhat2• 7 years ago

Friendly pedantry: in that video, you referred to vi as "vee"? :)

Ne02ptzero• 7 years ago

Looks awesome!

pjc50• 7 years ago

See "git format-patch" and "git am". The short name of "git am" is a hint that Linus probably used it a lot, given that git was built to replicate his personal idiosyncratic workflow.

(Obviously you have to use a command line mail client too, in keeping with git's spirit of user friendliness)

asveikau• 7 years ago

I have to say that format-patch and am workflow is really handy, even when working alone. (Say you want to test a commit on multiple dev machines but you're not sure if you're ready to push to a remote, as an example.) The flexibility to store or transmit a commit in patch form apart from .git or the remote, then seamlessly add it to the history, is a good thing.

u801e• 7 years ago

Obviously you have to use a command line mail client too

Not really. You could use a GUI client like Thunderbird to respond to emails pertaining to a particular commit as long as you're not actually trying to paste code in the composer. If you want to put something like a code snippet delimited by a "scissors line", then you'll need to use git format-patch and/or git send-email.

In other words, it doesn't matter what MUA (Mail User Agent) you use if you're just sending text, but if you are sending code in the form of a diff that someone will apply using git am, then you'll have to use a tool like git format-patch and git send-email to compose the message and send it.

crazysim3• 7 years 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_• 7 years 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.

crazysim3• 7 years 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.

deanclatworthy• 7 years 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.

WorldMaker2• 7 years ago

The Network graph has gotten increasingly buried in GitHub UX (currently it is under Insights > Network, at one point I recall it was a top level tab of its own) because it's a very useful power user feature, but can be super confusing to new users. (It's particularly a shame it is so hidden because IMNSHO it is the best commit graph that GitHub has, much more useful than the default commits list on the Code tab.)

The Network graph is extremely useful for getting a sense if a particular fork is dead and if there's a lot of activity happening on another fork (and letting you jump directly to other fork).

dcbadacd• 7 years ago

Assuming GitHub is willing to show you the graph, for some projects it isn't.

mustacheemperor• 7 years ago

It would be awesome if this problem was solved under Microsoft's ownership, it seems like the kind of challenge that could benefit from the resources of a giant firm, and of course promote Azure somehow. Code exactly duplicated from the parent repository could be excluded, so when you're searching Github you'd really be searching all of Github.

jdsully• 7 years ago

I run a fork, and we didn't use GitHub's "fork" feature for that specific reason. However its pretty trivial to checkout from a repository and push that wholesale into a brand new github repo without forking.

crazysim3• 7 years ago

I heard you can also contact support to separate this out too.

It's necessary to preserve issues and pull requests.

3JPLW5• 7 years 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_Cmpwn7• 7 years 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.

3JPLW5• 7 years 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.

twic2• 7 years ago

I can't think of any open source project which isn't a hard fork (the traditional kind you mention, with renaming etc) which has multiple branches of equal maximum status.

Many projects have research branches, integration branches, stabilisation branches, vendor branches, branches run by people with platforms or use cases not well served by the canonical branch, etc. But those examples are all either feeders for a canonical branch, or derivatives of it.

Are there any projects where there are multiple branches right at the top?

The closest i can come is in the various distros' versions of ancient common unix utilities, which are no longer maintained by their original creators. Distros will make fixes to them, and may exchange fixes, but there is no shared upstream. However, that is really a case of there being zero canonical branches, not more than one!

edflsafoiewq• 7 years ago

Is it any easier to move discussion that happened in an email thread?

Sir_Cmpwn7• 7 years ago

It's very easy. lists.sr.ht, for example, supports importing and exporting mailing list archives as mbox files (a well-known format for email storage).

perennate• 7 years ago

I'd argue that at least their API indicates they try to reduce rather than reinforce this lock-in. The API lets you build tools like https://github.com/colmsjo/github-issues-export to automatically export data from issues and other project data stored outside of git.

Moving this data is still not trivial but I don't think GitHub could unilaterally make it much easier.

(https://developer.github.com/v3/issues/)

organsnyder• 7 years ago

I'd love to see a standard develop for storing this information in-repo. GitHub could certainly drive such an initiative.

erk__2• 7 years ago

Well I guess they also have to make this possible as it is one of the principles in GDPR. Data portability

theyinwhy• 7 years ago

This is especially true for projects like Kubernetes which cross references to github PRs in its commit logs. Have fun figuring out the change history when github is down. And yes, of course K8s commits do provide more information that that. But the community is way more reliant on github than it probably should be. You really start to see that when comparing K8s to Linux Kernel commit messages.

erk__2• 7 years ago

I use magit-forge for emacs then you can have a local copy of the pr's and issues.

https://github.com/magit/forge

dmh2000• 7 years 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).

gowld2• 7 years 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.

johannes12343213• 7 years 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• 7 years 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.

dreamcompiler• 7 years 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• 7 years 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• 7 years 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• 7 years 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_Cmpwn7• 7 years 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__• 7 years 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.

What is a fork, and how GitHub changed its meaning

Related Stories