What is a fork, and how GitHub changed its meaning
drewdevault.com
drewdevault.com
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.
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.
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.
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.
Well, because you can treat it as a fully maintained source tree itself (and participating like a member in a bazaar). It's easy to turn on issues locally, add collaborators, accept pull requests, and trade commits back and forth between the forks. Now, yes, GitHub does by default "link" it to the upstream repository and it even keeps tabs on how its history differs, but I'd call these features that reflect real use-cases.
Also amusing is how the repositories on kernel.org describe themselves; 149 use the word "fork". Sure, it's probably partly due to how GitHub uses this terminology, but I'd say it's a good thing that forking is no longer pejorative by default — now it's a "hard fork" that's a bad thing.
There is no technical reason to do that, but that is insufficient in presence of social reasons: Someone wants to exploratory tinker around, maybe scratch some personal itch. No problem, check out, go wild in the working copy. Pretty soon they want it backed up in the cloud, maybe transfer it to another machine. VCS to the rescue. But do you want to create a branch on the official repository? Hell no, definitely not ready for that. git veterans will casually add another remote (and even that won't be as good as a branch/"github fork"), but a lot of people would choose the devil they know, rm .git and reinitialize. Everybody loses. The forker loses history, easy merges from upstream and almost all chances of getting merged back into upstream. The project loses a potential committer and general overview of what is going on at the fringes. Github wastes traffic and storage and loses the moat that socially linking up forker and project would have been.
Github "fork" strikes the perfect balance between proximity and distance: all the benefits of a branch, all the freedom of working in your own personal account. With this github have solved the problem of source dump repos so hard that we easily forget that it ever existed.
I doubt that. Git inherently allows pushing and pulling from anywhere. You can easily create a new repo on GH and push your branch(es) from your local clone there. Creating a new clean repo is more work. See how Linux works.
Github has a bunch of issues, but the way they fork is not in my top 3.
Characterizing a site where literally the entire development process can be done in the open as the cathedral model is a serious misreading of the The Cathedral and the Bazaar.
Even in your linux examples, people still generally recognize an "upstream" and "downstream" (perhaps we could call that a 'lineage'), don't they?
Because, I suggest, a totally decentralized flat horizontal list of repos without any notion of "upstream" and "downstream" isn't actually too useful in practice. I'm not sure that's related to "cathedral" vs "bazaar".
It's possible github encourages 'cathedral' thinking/behavior somehow by the nature of the featureset, but your argument hasn't convinced me of that; or that, even if so, it's intentional.
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!
Famitracker is a NES composing program. It was originally a monolithic cathedral project written by jsr without a Git repo. There were several forks made, including HertzDevil's 0CC-Famitracker which had a Github repo and added features. Famitracker's creator released a "beta" without source code, then abandoned the project. 0CC-Famitracker reverse-engineered the binary to merge in some features. I maintained a "bugfix patch-set" on top of 0CC for several months, but kept running into merge conflicts, so I ended up forking an older revision of 0CC, calling it j0CC, because 0CC's maintainer was adding bugs and refused to accept contributions (including bug fixes). Then we both abandoned our forks...
libgme is a library which emulates game-console sound chips, and is used in media players. It was originally written by blargg, but now has 2 active forks: A "linux" fork packaged in many Linux distros (including Ubuntu/Fedora), currently lightly-maintained by mpyne (which suffered a security vulnerability), and a "windows" fork used with foobar2000 (also builds on Linux via qmake) maintained by kode54, which is more ambitious with changes, including a slow but accurate SNES SPC700 emulator written by byuu and not affected by the security vulnerabilities.
I heard Amiga emulation (UAE) has multiple forks too, and WinUAE is more popular?
I would prefer if the forks had never happened, but it's not going to happen.
I know Drew is working on a few email things for the `todo` section of the site. Opening tickets, and responding via email.
> Can I participate in tickets on Sourcehut without creating an account?
Depends. I set up most of my public ones to allow anonymous users to contribute, but it's up to the owner to decide whether they want that or not.
Moving this data is still not trivial but I don't think GitHub could unilaterally make it much easier.
Other large projects include Tcl/Tk and many related extensions, as well as all the cool stuff I write:
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.
Sure, they're doing things to further their own popularity... But it doesn't appear to be at the expense of anyone else.
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.
Yes, but in a practical sense it ties your operation to GitHub.
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.
Even if everyone used github, they're still using vanilla git underneath.
The same is true for tracking forks and managing pull requests.
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.
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.
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).
git clone ssh://example.com/repo.git
[... Edit ...]
git push ssh://myserver example.com/myrepo.git master
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.
(Obviously you have to use a command line mail client too, in keeping with git's spirit of user friendliness)
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.
That said, given the nature of git, I usually just fall back to clone/grep.
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.
Here’s an example of a fork that you can search: https://sourcegraph.com/github.com/uber/gonduit
Just change the repository owner/name in the URL to search any other one.
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).
Easiest example off the top of my head: https://github.com/DefinitelyTyped/DefinitelyTyped/network
It's necessary to preserve issues and pull requests.
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?
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?
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.
Fork is almost nothing, it's just a useful pattern.