14 ms·

A fork on GitHub is no fork

490 points by nielsole 9y ago

Laaas 9y ago
Well, I mean, what did you expect? You'd be able to cheat the system otherwise.
- lucideer 9y ago
  In what way? Genuinely curious
  - dalloriam 9y ago
    For instance, you'd be able to create private forks in an organization without paying for the Github organization, then keep this private fork once the original membership is canceled.
    - Touche 9y ago
      They could give you an option to make it public, if this is the concern.
    - lucideer 9y ago
      Removing access to the fork in that instance would make sense, but that's not what happened here. The author didn't fork in an organisation, he forked to his own personal Premium account. Which he continues to pay for.
- bobbytherobot 9y ago
  Not totally following you on this. Do you mean the system as in terms of Github's profit model?
- u801e 9y ago
  What if I just cloned the repo, created a repo of the same name under my own account and then pushed up my local clone to the new repo?
  - huslage 9y ago
    Nothing is stopping you from doing that. The preferred experience is not to do it though.
    - u801e 9y ago
      I should have completed my question in my earlier post. Specifically, would doing that instead of creating a fork through Github's interface prevent one from losing access to their project when the previous copy is deleted from Github?
      - BeeOnRope 9y ago
        Yes.
- paulgb 9y ago
  OP states that he still has unlimited private repos (presumably on a paid account) so it wouldn't be cheating the private repo limit in this case. GitHub could simply count a forked private repo against the account's private repo limit if the upstream repo is disabled to avoid the type of cheating I'm thinking of.
  - smoyer 9y ago
    I haven't paid for private repos (at least not for a few years) and yet I'm a member of several ... and I can fork them as needed without paying. In my case, I would expect that I would lose access to my fork if the private repo was no longer a paid account.
    - paulgb 9y ago
      Right, but I'm saying GitHub could allow you to keep accessing those cloned repos if the upstream repo was disabled as long as you switch to a paid plan. I.e. they could treat it the same way they treat your own private repos when you go from a paid to unpaid plan.
      - smoyer 9y ago
        Yes ... it could be that if either of the private repos was paid, they would be available.
inetknght 9y ago
> this taught me not to rely on Github as only storage for code If you didn't already know this, then... good lesson to learn. Just like backups: don't rely on a single source of anything.
- burner5692 9y ago
  Yet, most users are content with GitHub being the sole owner of their issues, pull requests, code review, wiki...
  - FLUX-YOU 9y ago
    This is typical. Most businesses don't duplicate their workflow stuff to a parallel system because database backups are sufficient. GitHub, even with relatively recent issues and downtime, has better infrastructure and skilled personnel than most companies hosting their own instances of these services on some reclaimed box.
    - piracykills 9y ago
      Even if they have great infrastructure, this article is evidence that they can still take you down at any given moment if they so much as feel like it. You need those database backups.
      - hashkb 9y ago
        Or you can pay them and not violate their terms. Outrage over GitHub admin actions is loud, but for the 99.999% of cases everything is fine.
        burner5692 9y ago
        With 26 million users, five nines is not very reassuring.
        deleted 9y ago
        [deleted]
kenrick95 9y ago
Well, it is stated on the help page, regarding private repositories and its fork: https://help.github.com/articles/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility/ https://help.github.com/articles/what-happens-to-forks-when-... > Private forks inherit the permissions structure of the upstream or parent repository.
- nielsole 9y ago
  Ah, thanks for pointing me to it. I still find the behaviour unintuitive, but at least it is documented somewhere.
pandler 9y ago
At least on Bitbucket they're pretty explicit about the rules around forks. Creating a new private repository, you get the option to select [No Forks | Allow Forks | Allow only private forks]. I don't see any kind of configuration like that on github.
- dfansteel 9y ago
  Does that differentiation necessarily mean Bitbucket repos are immune to this problem?
  - pandler 9y ago
    No of course not. They're just a bit more explicit about the fact that permissions can persist across forks.
- incognito2375 9y ago
  That is silly either way. Once you have a local copy you can just push that copy to any git hoster and thus make it public. Forking through their web ui is just a convenience feature.
- Bellyache5 9y ago
  GitHub gives you the option to allow/disallow forking for private repos at both the repo and organization level. https://help.github.com/articles/allowing-people-to-fork-private-repositories-in-your-organization/ https://help.github.com/articles/allowing-people-to-fork-pri...
gaius 9y ago
Git is a DVCS, this is only an issue if you use it as if it were a traditional VCS.
- dboreham 9y ago
  Which is how almost everybody uses it, so not such a helpful observation.
  - megous 9y ago
    Unless people are doing shalow clones, almost everybody uses git as DVCS.
    - gaius 9y ago
      If that were true the article author would not have encountered this issue
      - megous 9y ago
        Author was presumably saved by this (old local copy).
    - magila 9y ago
      There's a little more nuance to it than that. While git users generally keep a local copy of a repo, collaborating with others is pretty much always done through a central server. Git users could theoretically collaborate without a central server, but it currently a far too manual process to be considered practical. There were a couple of attempts to implement decentralized collaboration in git under the name gittorrent, but those didn't go anywhere. Failure is understandable in this space, decentralized collaboration is a _hard_ problem and the tools to do it are still in their infancy. IPFS is probably the furthest along at this point and they're still a long ways away from having something production ready.
      - megous 9y ago
Ne02ptzero 9y ago
I think a fork is just an internal branch on the original repositoriy for the Github Servers. From a data / sys admin point of view, it makes sense, since a hard-copy of a repository (and all the git objects with it) is just generally useless.
- Nerdfest 9y ago
  I would guess that it's stored and dealt with using a basic "copy on write" strategy. It's functionally a copy, which is all that usually matters. This may have been an oversight.
  - OskarS 9y ago
    Yeah, I wouldn't be surprised if this was an oversight as well. I can't imagine that GitHub would delete the git blobs from their servers, even if you stop paying (harddrives are cheap!).
  - philipwhiuk 9y ago
    It's a bit more complex than that actually. https://www.youtube.com/watch?v=-ZNKR9wFe8o https://www.youtube.com/watch?v=-ZNKR9wFe8o
thriftwy 9y ago
Just yesterday on HN I was recommended of git-ssb. I think it's time.
hashkb 9y ago
In the alternative case, a company who terminates an engineer can't prevent them from accessing the code if they've forked it. This is a"problem" with git, which GitHub has tried to solve for its paying customers. Whether or not you agree... GitHub has worked like this for years.
- Someone1234 9y ago
  If GitHub wants to implement DRM-like copy control, they should implement actual DRM-like copy control, and leave fork the heck alone. Part of the problem is that instead of being explicit about how things work they're being implicit. Instead of users being told a fork is not a, you know, fork they're lied to only to have the fork vanish later. Why is there no banner at the top of the repo warning you this is a fake repo? Why is there no ability for the original owner to delegate a full fork to the children? If this implemented this correctly you'd expect to have control over how it works (or turn it off).
cdancette 9y ago
I think the last sentence may be wrong > I haven’t tried contacting customer support, but as this appears to be official policy I would not expect a change there. I'm sure the support would be able to do something for you there, anyway it's always good to contact them, even if they can't do anything, before saying things like this online.
- alex_hitchins 9y ago
  I disagree. People need to be aware of this before it becomes an issue for them. Git is distributed and yes, relying on one resource is a risk in itself, however - if a fork isn't a fork it should be made clear.
  - cdancette 9y ago
    yes but the point is he didn't even ask the support so his claims are just wrong. Maybe the support will always replace your fork with a copy if you just ask. I agree the UX is bad though and should be improved
    - alex_hitchins 9y ago
      My point is he shouldn't have to ask support to let him have access to something he took a fork of. Bad UX aside, a fork allows one to think of a permanent branch that is distinct from the original. This is not the case.
- tarantulaslash 9y ago
  A fork on GitHub is no fork.
fouc 9y ago
A possible workaround? Fork a private repo. Make it public, thus forcing a new repository network to be made. Then take it private again if you choose. In the case of a public fork, it seems you're safe from it getting taken out from you. (relatively speaking)
- Someone1234 9y ago
  The fact you have to do this to make a fork, fork, is problematic. You could also download the fork, and then upload it again as a new root, but in both cases it entirely defeats the point. A lot of people are coming up with workarounds or blindly defending Github in this thread. I think I'm the only way that sees this decision was done for commercial reasons ($), and has nothing to do with people "maintaining control of their private repo." Frankly if fork doesn't, you know, fork due to some quirk in some random article you aren't going to read or find that to me is a massive black mark against Github. That's all I care about, Github working like Git, in most major ways.
  - ben509 9y ago
    `I think I'm the only way that sees this decision was done for commercial reasons ($)...` Is it fair for me to expand "for commercial reasons" as: Github is a for-profit business, and their business model is to provide a service to users and that also requires them to be able to turn that service off when customers stop paying. `... and has nothing to do with people "maintaining control of their private repo."` I disagree here, I think you're using a notion of "control" that is too narrow. A notion that captures the scope better would be that Github is adding value by enabling project management and collaboration. The ability to do pull requests, manage issues, etc. is all tied to forking. That's what makes their service worth paying for, and it's also what they have to turn off if you don't want to pay. `That's all I care about, Github working like Git, in most major ways.` What you're saying here is reasonable enough I expect you can find providers that are pretty close to that standard, and it's a fair point that Github's business model has some sharp edges. In this case, it's a consequence of "we turn the lights off if you don't pay," and an alternative has to deal with the same bottom line.
- 9y ago
cup-of-tea 9y ago
Git is a distributed version control system and Github is not in a privileged position. Don't treat it like it is. Github is a convenience. Nothing more. "Forks" are really just branches and branches are really just references. Forking just adds a few more references to the same repository.
- jeremiep 9y ago
  You realize that implementing forks as branches creates a LOT more work for Github to make it work? It makes absolutely no sense for them to do so. A copy-on-write fork is most likely what is being implemented.
  - cup-of-tea 9y ago
    What do you mean? What's the difference between a fork and a branch? It's not copying anything.
  - Gaelan 9y ago
    I believe that GitHub stores all forks in a network with a single git object store.
tokenizerrr 9y ago
Did you contact GitHub regarding this and ask them, before bashing them on social media? What was their response? They'll probably gladly remedy the situation.
- nielsole 9y ago
  > Luckily I found an old local copy of my project [...] I haven’t tried contacting customer support, but as this appears to be official policy I would not expect a change there. The policy itself needs to be changed, the individual case is resolved.
  - luckyorlame 9y ago
    More like lame. You should have contacted their support before bashing them in public. There rationalization for this (owner of original fork is the owner) seems pretty reasonable as long as the repo is private.
    - asimpletune 9y ago
      No, that doesn’t make sense.
  - tokenizerrr 9y ago
    Or the policy was misinterpreted. The piece of text that got quoted is present in every single EULA ever and does not at all indicate if this is actually intentional by GitHub. Besides, you can request to disconnect your fork from an upstream project. I expect such a request will also resolve this problem.
johndbritton 9y ago
Hey Niels! I'm John, and I work at GitHub. Sorry to hear you're having difficulty. From your post: > I haven’t tried contacting customer support, but as this appears to be official policy I would not expect a change there. I'd recommend you reach out to support@github.com, they're usually very helpful with things like this.
- nielsole 9y ago
  Hey John, thanks for reaching out. The individual case was resolved (found a local copy). But I find the policy worrisome for future projects. If the customer support was happy to reenable access for me, what is the point of the current policy?
  - crankylinuxuser 9y ago
    That's why I've been migrating my Github/lab projects to IPFS as well. I have a few cheap VPSes I have my stuff pinned. "Cloud" (read: someone else's server) is unreliable at best, or malicious at worst like this case. The people may not be bad actors, but the tech definitely is.
    - bringtheaction 9y ago
      Would like to hear more about your git with IPFS workflow.
    - icebraining 9y ago
      How are VPSs not on someone else's server too?
- kercker 9y ago
  If people can get the fork back after reaching out to support@github.com, why would not GitHub resolve this issue once and for all, so that people will not need to reach out to support@github.com any more?
- philipwhiuk 9y ago
  If Support just do this kind of thing why not put it in the UI. It's like unlinking a fork - GitHub Support just do it on asking - but why is GitHub spending unnecessary manpower when it could just be a button in the settings saying 'Unlink'.
Arqu 9y ago
The author states that he didnt bother with support (luckily he had a local copy) so here are my 2 cents I've been in the exact same spot under very similar circumstances. What I can add is that the github support was great, we got it resolved within the working day. The repo was "deleted" to free up the private repos of my colleague but we didnt know that the fork on my account would go down with it. Its been probably a couple months till we got back to it and noticed the issue. They managed to recover the repo and unblock my fork. I just did a fresh repo and moved everything over. While it is odd behavior, if its really bad they will probably manage to get you back on your feet. Also Im not affiliated with github in any way just have some repos from student days over there. If it matters im on gitlab and google repos
- newsat13 9y ago
  So they keep copy of code after it's deleted?
  - Sir_Substance 9y ago
    In their business-continuity backups, you'd have to assume yes. However, I would certainly be surprised if a Github support staff member went and fished out the off-site backup and mounted it to recover one missing repo. You'd hope that would require quite a few staff members to orchestrate. But in general, yeah. Most engineers don't think about deletion very hard when they start designing a system, and it's also convenient (although with GDPR possibly soon illegal, situation dependent) for auditing and research to merely flag things as deleted and not show them to the customer. As a result, true data deletion generally gets justified away as a bit inconvenient and not really desirable anyway, and almost no software company really deletes anything on demand. Best you can hope for is semi-annual data purges to reclaim disk space. If this bothers you, consider joining us in the world of self-hosting your services. Gitlab is in my opinion considerably better than Github anyway. Certainly it's worth spinning up a docker container and taking a peek around.
zimbatm 9y ago
Related to that: if a private repo is forked, the target account doesn't need a paying subscription. In that sense, it's the root repository holder that is paying for the new private repo. I'm not arguing if it's a good or bad thing, it just seems consistent in that regard.
IAmEveryone 9y ago
This seems to be an edge case, affecting only private repositories. I can see how this can make sense in that context. Can we do without the pitchforks? (pun intended)
- ahnick 9y ago
  It still doesn't make sense in that use case. He could have cloned it to his local machine and still had access to the code. Had he done that he could have pushed it back to github as a completely new repository thereby creating a legitimate fork. It's a silly requirement from github.
snowwrestler 9y ago
As someone who runs a bunch of private repos on Github, and hires freelancers and vendors to work on them, I like the way Github manages forks of private repos. When I end a relationship, and remove that person from my private repo, I want their fork of my code to go away too. Why? Because it's cleaner. It means there are no abandoned copies of my codebase sitting around forever forgotten in random Github accounts. I set up a private repo because I want to control access to my code. That's why a private repo is private. It also makes it harder for people to misrepresent their relationship to me later on. Sure, anyone with read access to one of my repos can pull it down and save a local copy. But that is different from logging into Github and having a fork of my repo. A Github fork looks and works differently from a local copy. This whole situation seems weird because the idea of a "private" repo is not inherent to how git was intended to work; it's something Github invented to make money. So I'm not surprised that it violates people's expectations sometimes.
- fwdpropaganda 9y ago
  That makes no sense to me. You're relying on people not making their forks out of github. If that strategy works at all, it's incidental and I wouldn't rely on it for anything that matters.
  - sdrothrock 9y ago
    > You're relying on people not making their forks out of github. That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code."
    - fwdpropaganda 9y ago
      > That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code." No, he made two points. The first one is that this way you don't have your code in random freelancer's accounts, which I'm saying is wrong: a freelancer can take his code, and upload it back to his account. So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts, you're mistaken too. In fact if you don't believe me give me access to your private repos and lets see what happens.
deleted 9y ago
[deleted]
MattyRad 9y ago
I forked Popcorn Time when it came out, just because I was impressed with the app and I wanted to look over (and possibly modify) the code. I only forked in though, I didn't clone it locally. A week later when I had some free time to do so, same issue, my personal fork disappeared. It was mildly aggravating, but also a soft reminder to question how much trust to put into third-parties.
- dspillett 9y ago
  I wouldn't call it a trust issue, but a due diligence one: making sure you do enough to ensure anything you care about is safe. In this instance making sure that you understand the service you are using (including intricacies like this), or keeping an extra backup of your own (a locally cloned copy of the repo), or for proper paranoia, both of the above. No matter how much you trust github and those in positions of responsibility for the projects you interact with, if you don't know the exact details of the feature-set you can come unstuck due to operating under false impressions. Github has done nothing wrong, as that is how the service is intended to work and it is documented as such (though it would appear some of the documentation is incorrect or at least inconsistent?), but you still get an inconvenient surprise because of a misunderstanding. A little paranoia can be very useful!
  - snugghash 9y ago
    I'd argue this is barely worth the time spent. You'd use at least a hundred services of this sort, with a flux of at least one a week. 2-3 hours reading up on intricacies, setting up backups for your data? It's a crazy amount of time to spend on something you dont care about - you just want it to work.
    - dspillett 9y ago
      If argue that if you care enough about the content that you'll do more than say "oh well" to yourself if it becomes inaccessible, then researching this sort of thing or (probably easier but maybe more costly in terms of bandwidth use) rigging it up to your existing backup infrastructure is the minimum effort you did make. If you don't you have no high ground from which to complain or blame others from if it going away inconveniences yourself. If you don't care about it that much, why do you keep it anyway?
masklinn 9y ago
https://blog.github.com/2015-07-02-greater-control-over-forks-of-your-private-repositories/ https://blog.github.com/2015-07-02-greater-control-over-fork...
Nokinside 9y ago
>GitHub has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. GitHub reserves the right to refuse service to anyone for any reason at any time. Companies write these "We are can do whatever" clauses to license agreements so that they can point to them and make people go away. IANAL, but EULA terms like are typically in breach with Consumer Law protections against unfair contract terms. If you are private person (consumer) paying for a service, this kind of term may be null and void.
deleted 9y ago
[deleted]
kylecordes 9y ago
Some of the strain here is around two very different meanings of the word "fork", but only a single feature with that name on GitHub: 1) When I want to contribute to a project, make some local changes and offer them back to the mainline, I fork. My fork is a pseudo-throwaway thing; it contains code that is hopefully destined either to make it back to mainline, or likely to be abandoned if mainline moves on in active development. 2) When I want to go my own way with a project, using it as a starting point for a new direction of development that may wander in a direction quite far from the original (it might get renamed, it might continue development of the original becomes abandoned, etc.), I also fork. Numerically meaning 1 is surely far more common, so it makes sense for the GitHub features and permissions etc., to optimize for that case. Meaning 2 is closer to the original idea of a fork, from open source vernacular long predating GitHub. Naming is hard, and I don't blame them for picking a single name for these two technologically similar (but socially different) scenarios.
- jehlakj 9y ago
  I don’t know much of the historical details, but whenever I think of a fork, I think of processes. I think that GitHub’s official definition is just a simplification of what happens as a side effect.
- styfle 9y ago
  I don’t think GitHub actually labels #2 as a fork, but traditionally that’s been the meaning. They just needed a word to show that the repo is not original and is tied to an upstream repo. For example, when I wanted to “fork” a project[0] that was no longer maintained and not accepting PRs, I actually had to contact GitHub to “unlink” my repo so that I my repo could be standalone and utilize all the features on GitHub (can’t remember which features off the top of my head). [0]: https://github.com/styfle/geoslack https://github.com/styfle/geoslack
  - brianpan 9y ago
    I think you're right. So my conclusion is....a fork on GitHub is no fork.
jbfoo 9y ago
You might use gitlab to clone your github repos. Web interface to clone them is super easy (obviously you can do it from the console also), there is no limit to private repos (their business model seems to be charging for CI time and selling on-premise licenses). I'm not affiliated with either hosting services and I use both :)
hartator 9y ago
Hum, I would think it’s to avoid spreding of private company repositories when employees get terminated. It does make sense.
bhauer 9y ago
> Luckily I found an old local copy of my project, but this taught me not to rely on Github as only storage for code. This is the distillation. If something matters to you, you should personally take responsibility for its long-term storage. Apparently for the author, finding a true duplicate was just luck. To minimize the risk, maintain multiple copies on multiple media. Github is only one medium. The context is especially notable: this is source code and source code is (in a majority of cases) very small. Maintaining personal archives of project source is a comparatively simple and low-cost matter.
- gkya 9y ago
  How reliant people are on Github is puzzling. If Github somehow failed one day, many businesses and OSS projects would just fail to operate. What surprises me is that software teams in companies use it too, when just sending commits/patches around is quite easy with any VCS.
  - katastic 9y ago
    Kind of like how that one NPM package took down like 14,000 other packages when someone took a DMCA request against an author's OTHER package and he just took them all down in protest--which took down their dependencies and their dependencies and ... "broke the world". https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ The code in question was like 11 lines of code (with curly and spaces!!) for calculating left-hand padding for a syntax highlighting code box.
AdmiralAsshat 9y ago
Does this apply to public repos? I have a close friend who past away a few months ago, and wanted to try to find some way to preserve all of his GH repos for his wife and children. I've locally cloned all of them, but the prospect that GH might delete all of his stuff if he fails to login for a certain amount of time or something is deeply concerning. I don't suppose GH has some kind of memorial/preservation mode the way Facebook does?
- knownothing 9y ago
  > Every user account and organization on GitHub can have unlimited collaborators on any number of public repositories. From: https://help.github.com/articles/github-s-billing-plans/ https://help.github.com/articles/github-s-billing-plans/ So if your friend's repositories are all public no payment is required.
- icebraining 9y ago
  "Inactive accounts may be renamed or removed by GitHub staff at their discretion." https://help.github.com/articles/name-squatting-policy/ https://help.github.com/articles/name-squatting-policy/ There are a few blog posts of people who got GH support to release the names of inactive accounts, though it's not clear if those accounts had any repos at all.
- Avamander 9y ago
  You can ask for a fork to be unlinked politely. Done that for a few times to re-enable search and etc.
gkya 9y ago
I observe that people "fork" repositories (which is basically a cheap clone rather than a fork, bad terminology there) not for having a copy of their own to work on, but more like a glorified "like/+1/star". So even with public repos, it seems quite acceptable that Github tries to deduplicate aggressively.
jrochkind1 9y ago
Apparently there's no github web UI to actually copy a repo so it's not listed as a fork, but of course git makes it quite possible, and github even provides directions, using git directly. https://help.github.com/articles/duplicating-a-repository/ https://help.github.com/articles/duplicating-a-repository/ I'm imagining a browser plugin that notices when a repo you are about to fork is private, and (or even without that) adds a 'copy' button which gives you text to copy-and-paste into your terminal to make a true copy.
peteey 9y ago
Is fork part of git? I don't see it mentioned in the official documentation: git-scm.com Fork seems like some feature cloud storage services invented.
- Gaelan 9y ago
  The terminology is a GitHub-and-friends thing, but the idea is at the core of git. When you clone a repository, you're creating a "fork" of the repo on your own computer. Git is a DVCS (distributed VCS), where you can make many copies/forks of a repository and freely push/pull commits between them. (As opposed to something like SVN, where the repository lives on a single server, and all commits go directly to that server without a separate "push" step.)
  - chungy 9y ago
    The terminology is at least a couple decades older than GitHub has even existed, and was even mentioned somewhere by Linus in the creation of Git. Fork used to have a very negative connotation, and that was related to the difficulty required to pull one off. When you forked a project, you had to set up your own hosting, web space, issue tracker, version control system (and you probably couldn't clone and start off the upstream's VCS), and so forth. The technical barrier made it so that you only forked a project when you have severe disagreements with upstream; some of the most famous in history include EGCS from GCC, and XEmacs from Emacs. With DVCSes, including Git, much of that technical difficulty is automatically removed. Every clone can potentially be a fork (as in, a new independent project), and this was one of Linus's intentions. If forking is easy, it keeps upstream on their toes. After being adopted by DVCS hosting sites like GitHub, it turned around to being a positive term even.
nlo 9y ago
If you want a mirror of a repository, self hosted Gogs/Gitea is a great way to do this in a way that makes you unbeholden to the upstream.
greggman 9y ago
This is no different than Google Docs and many other similar services. If you share a Google Doc with someone it will show up in their list of Docs. But it is just a reference to "their" doc. If they delete the doc there's no doc to reference and your "apparent" copy of the doc (which was really just a reference) disappears. If you really wanted your own personal copy you need to make a duplicate. That duplicate will be yours not a reference to theirs. It was strange the first time I ran into it. I deleted an account. I had shared the documents with another account of mine. Then I noticed when I deleted the first account I lost access to those docs. Now I know I hadn't copied the docs I'd only had references to them. Next time I'll know to make copies if I actually want copies and not just access to another account's shared docs.
urda 9y ago
Backups, backups, backups, BACKUPS. Don't rely on GitHub being your only source location. Git is a DVCS, meaning you don't have to have a single upstream. Make sure you are pushing / mirroring to a third party (GitLab, Bitbucket, personal Git Server, etc)
- kardos 9y ago
  Do you know a good way to automate that?
  - philipwhiuk 9y ago
    $ vi /usr/bin/gpa #!/bin/bash git push github $? git push bitbucket $? $ gpa
  - fenwick67 9y ago
    a crontab script that does `git fetch` would be enough
  - urda 9y ago
    You could have a cron job automatically sync repos, but right now I have my own local copies and I use GitLab's "Repository mirroring" [1] which has worked really well for me! [1] https://docs.gitlab.com/ee/workflow/repository_mirroring.html
discordianfish 9y ago
This is also simply to their per private repo pricing model. You can fork private repos with a free account. I'd just ask github support about this particular issue and I'm pretty sure they'll can either make the repo open or at least make the code available to you somehow.
EdSharkey 9y ago
So it sounds like active links between forks is intended to mirror the valid links between people/organizations that are doing business with one another. If people or organizations end their relationship, then there's a way to cutoff any secondary contributors to the codebase to have the ability to make pull requests from -and- receive code updates. At first blush, I thought, "GitHub is mean and just locking-in their paying customers forever!!" But now after reading the comments here, I think this is a very pretty way to represent the nuances of a fork relationship. If the original owners of a private codebase disappear, then it is reasonable and just that all of the forks to their code should as well. I believe it's reasonable and just because GitHub have no way to interpret _why_ the original owner dropped off and must respect their ownership by breaking the relationship.
tracker1 9y ago
On the one hand, it bugs me when I see a repo that was obviously cloned/forked from another REPO and uploaded new without the github (fork) link to the original... but upon seeing this, I many have to reconsider doing that with a few repositories. When I left a prior job, I forked and took over updates of a relatively popular open-source library under my own GH account... I'd hate to see it all disappear because someone from a former job decides to nuke the upstream repo.
curryz 9y ago
A Private Fork Is No Fork ...b-b-but muh snippet! Shame on you Github! You were supposed to babysit me! ~ T. Dipshit
HIPisTheAnswer 9y ago
And this is why I dont have a github account. One day, all those foolish users will be left hanging, crying for the dust which has replaced their code and CI. The deserve worse; they have enabled this central organization to subvert the heart of OSS. May github go down forever, along with google translate and all those other projects which have crippled our technical progress.
Ilyes512 9y ago
This really sucks... I know companies that made forks of public (opensource) repo's just to have a "backup" in case the person or organisation decides to take down the repo. This should really be fixed as I don't see ANY benefit in the current way github handles this now. People talking about giving contractor's or other third party people access to later revoke them (after they are done) thinking they wont have a copy, are just plain simple wrong. Git is decentralised and the contractor/dev will always have his code on his machine unless HE decides to delete it.

490 points by nielsole 9y ago

Laaas 9y ago

Well, I mean, what did you expect? You'd be able to cheat the system otherwise.

lucideer 9y ago
In what way? Genuinely curious
- dalloriam 9y ago
  For instance, you'd be able to create private forks in an organization without paying for the Github organization, then keep this private fork once the original membership is canceled.
  - Touche 9y ago
    They could give you an option to make it public, if this is the concern.
  - lucideer 9y ago
    Removing access to the fork in that instance would make sense, but that's not what happened here. The author didn't fork in an organisation, he forked to his own personal Premium account. Which he continues to pay for.
bobbytherobot 9y ago
Not totally following you on this. Do you mean the system as in terms of Github's profit model?
u801e 9y ago
What if I just cloned the repo, created a repo of the same name under my own account and then pushed up my local clone to the new repo?
- huslage 9y ago
  Nothing is stopping you from doing that. The preferred experience is not to do it though.
  - u801e 9y ago
    I should have completed my question in my earlier post. Specifically, would doing that instead of creating a fork through Github's interface prevent one from losing access to their project when the previous copy is deleted from Github?
    - BeeOnRope 9y ago
      Yes.
paulgb 9y ago
OP states that he still has unlimited private repos (presumably on a paid account) so it wouldn't be cheating the private repo limit in this case. GitHub could simply count a forked private repo against the account's private repo limit if the upstream repo is disabled to avoid the type of cheating I'm thinking of.
- smoyer 9y ago
  I haven't paid for private repos (at least not for a few years) and yet I'm a member of several ... and I can fork them as needed without paying. In my case, I would expect that I would lose access to my fork if the private repo was no longer a paid account.
  - paulgb 9y ago
    Right, but I'm saying GitHub could allow you to keep accessing those cloned repos if the upstream repo was disabled as long as you switch to a paid plan. I.e. they could treat it the same way they treat your own private repos when you go from a paid to unpaid plan.
    - smoyer 9y ago
      Yes ... it could be that if either of the private repos was paid, they would be available.

inetknght 9y ago

> this taught me not to rely on Github as only storage for code If you didn't already know this, then... good lesson to learn. Just like backups: don't rely on a single source of anything.

burner5692 9y ago
Yet, most users are content with GitHub being the sole owner of their issues, pull requests, code review, wiki...
- FLUX-YOU 9y ago
  This is typical. Most businesses don't duplicate their workflow stuff to a parallel system because database backups are sufficient. GitHub, even with relatively recent issues and downtime, has better infrastructure and skilled personnel than most companies hosting their own instances of these services on some reclaimed box.
  - piracykills 9y ago
    Even if they have great infrastructure, this article is evidence that they can still take you down at any given moment if they so much as feel like it. You need those database backups.
    - hashkb 9y ago
      Or you can pay them and not violate their terms. Outrage over GitHub admin actions is loud, but for the 99.999% of cases everything is fine.
      - burner5692 9y ago
        With 26 million users, five nines is not very reassuring.
      - deleted 9y ago
        [deleted]

kenrick95 9y ago

Well, it is stated on the help page, regarding private repositories and its fork: https://help.github.com/articles/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility/ https://help.github.com/articles/what-happens-to-forks-when-... > Private forks inherit the permissions structure of the upstream or parent repository.

nielsole 9y ago
Ah, thanks for pointing me to it. I still find the behaviour unintuitive, but at least it is documented somewhere.

pandler 9y ago

At least on Bitbucket they're pretty explicit about the rules around forks. Creating a new private repository, you get the option to select [No Forks | Allow Forks | Allow only private forks]. I don't see any kind of configuration like that on github.

dfansteel 9y ago
Does that differentiation necessarily mean Bitbucket repos are immune to this problem?
- pandler 9y ago
  No of course not. They're just a bit more explicit about the fact that permissions can persist across forks.
incognito2375 9y ago
That is silly either way. Once you have a local copy you can just push that copy to any git hoster and thus make it public. Forking through their web ui is just a convenience feature.
Bellyache5 9y ago
GitHub gives you the option to allow/disallow forking for private repos at both the repo and organization level. https://help.github.com/articles/allowing-people-to-fork-private-repositories-in-your-organization/ https://help.github.com/articles/allowing-people-to-fork-pri...

gaius 9y ago

Git is a DVCS, this is only an issue if you use it as if it were a traditional VCS.

dboreham 9y ago
Which is how almost everybody uses it, so not such a helpful observation.
- megous 9y ago
  Unless people are doing shalow clones, almost everybody uses git as DVCS.
  - gaius 9y ago
    If that were true the article author would not have encountered this issue
    - megous 9y ago
      Author was presumably saved by this (old local copy).
  - magila 9y ago
    There's a little more nuance to it than that. While git users generally keep a local copy of a repo, collaborating with others is pretty much always done through a central server. Git users could theoretically collaborate without a central server, but it currently a far too manual process to be considered practical. There were a couple of attempts to implement decentralized collaboration in git under the name gittorrent, but those didn't go anywhere. Failure is understandable in this space, decentralized collaboration is a _hard_ problem and the tools to do it are still in their infancy. IPFS is probably the furthest along at this point and they're still a long ways away from having something production ready.
    - megous 9y ago

Ne02ptzero 9y ago

I think a fork is just an internal branch on the original repositoriy for the Github Servers. From a data / sys admin point of view, it makes sense, since a hard-copy of a repository (and all the git objects with it) is just generally useless.

Nerdfest 9y ago
I would guess that it's stored and dealt with using a basic "copy on write" strategy. It's functionally a copy, which is all that usually matters. This may have been an oversight.
- OskarS 9y ago
  Yeah, I wouldn't be surprised if this was an oversight as well. I can't imagine that GitHub would delete the git blobs from their servers, even if you stop paying (harddrives are cheap!).
- philipwhiuk 9y ago
  It's a bit more complex than that actually. https://www.youtube.com/watch?v=-ZNKR9wFe8o https://www.youtube.com/watch?v=-ZNKR9wFe8o

thriftwy 9y ago

Just yesterday on HN I was recommended of git-ssb. I think it's time.

hashkb 9y ago

In the alternative case, a company who terminates an engineer can't prevent them from accessing the code if they've forked it. This is a"problem" with git, which GitHub has tried to solve for its paying customers. Whether or not you agree... GitHub has worked like this for years.

Someone1234 9y ago
If GitHub wants to implement DRM-like copy control, they should implement actual DRM-like copy control, and leave fork the heck alone. Part of the problem is that instead of being explicit about how things work they're being implicit. Instead of users being told a fork is not a, you know, fork they're lied to only to have the fork vanish later. Why is there no banner at the top of the repo warning you this is a fake repo? Why is there no ability for the original owner to delegate a full fork to the children? If this implemented this correctly you'd expect to have control over how it works (or turn it off).

cdancette 9y ago

I think the last sentence may be wrong > I haven’t tried contacting customer support, but as this appears to be official policy I would not expect a change there. I'm sure the support would be able to do something for you there, anyway it's always good to contact them, even if they can't do anything, before saying things like this online.

alex_hitchins 9y ago
I disagree. People need to be aware of this before it becomes an issue for them. Git is distributed and yes, relying on one resource is a risk in itself, however - if a fork isn't a fork it should be made clear.
- cdancette 9y ago
  yes but the point is he didn't even ask the support so his claims are just wrong. Maybe the support will always replace your fork with a copy if you just ask. I agree the UX is bad though and should be improved
  - alex_hitchins 9y ago
    My point is he shouldn't have to ask support to let him have access to something he took a fork of. Bad UX aside, a fork allows one to think of a permanent branch that is distinct from the original. This is not the case.
tarantulaslash 9y ago
A fork on GitHub is no fork.

fouc 9y ago

A possible workaround? Fork a private repo. Make it public, thus forcing a new repository network to be made. Then take it private again if you choose. In the case of a public fork, it seems you're safe from it getting taken out from you. (relatively speaking)

Someone1234 9y ago
The fact you have to do this to make a fork, fork, is problematic. You could also download the fork, and then upload it again as a new root, but in both cases it entirely defeats the point. A lot of people are coming up with workarounds or blindly defending Github in this thread. I think I'm the only way that sees this decision was done for commercial reasons ($), and has nothing to do with people "maintaining control of their private repo." Frankly if fork doesn't, you know, fork due to some quirk in some random article you aren't going to read or find that to me is a massive black mark against Github. That's all I care about, Github working like Git, in most major ways.
- ben509 9y ago
  `I think I'm the only way that sees this decision was done for commercial reasons ($)...` Is it fair for me to expand "for commercial reasons" as: Github is a for-profit business, and their business model is to provide a service to users and that also requires them to be able to turn that service off when customers stop paying. `... and has nothing to do with people "maintaining control of their private repo."` I disagree here, I think you're using a notion of "control" that is too narrow. A notion that captures the scope better would be that Github is adding value by enabling project management and collaboration. The ability to do pull requests, manage issues, etc. is all tied to forking. That's what makes their service worth paying for, and it's also what they have to turn off if you don't want to pay. `That's all I care about, Github working like Git, in most major ways.` What you're saying here is reasonable enough I expect you can find providers that are pretty close to that standard, and it's a fair point that Github's business model has some sharp edges. In this case, it's a consequence of "we turn the lights off if you don't pay," and an alternative has to deal with the same bottom line.
9y ago

cup-of-tea 9y ago

Git is a distributed version control system and Github is not in a privileged position. Don't treat it like it is. Github is a convenience. Nothing more. "Forks" are really just branches and branches are really just references. Forking just adds a few more references to the same repository.

jeremiep 9y ago
You realize that implementing forks as branches creates a LOT more work for Github to make it work? It makes absolutely no sense for them to do so. A copy-on-write fork is most likely what is being implemented.
- cup-of-tea 9y ago
  What do you mean? What's the difference between a fork and a branch? It's not copying anything.
- Gaelan 9y ago
  I believe that GitHub stores all forks in a network with a single git object store.

tokenizerrr 9y ago

Did you contact GitHub regarding this and ask them, before bashing them on social media? What was their response? They'll probably gladly remedy the situation.

nielsole 9y ago
> Luckily I found an old local copy of my project [...] I haven’t tried contacting customer support, but as this appears to be official policy I would not expect a change there. The policy itself needs to be changed, the individual case is resolved.
- luckyorlame 9y ago
  More like lame. You should have contacted their support before bashing them in public. There rationalization for this (owner of original fork is the owner) seems pretty reasonable as long as the repo is private.
  - asimpletune 9y ago
    No, that doesn’t make sense.
- tokenizerrr 9y ago
  Or the policy was misinterpreted. The piece of text that got quoted is present in every single EULA ever and does not at all indicate if this is actually intentional by GitHub. Besides, you can request to disconnect your fork from an upstream project. I expect such a request will also resolve this problem.

johndbritton 9y ago

Hey Niels! I'm John, and I work at GitHub. Sorry to hear you're having difficulty. From your post: > I haven’t tried contacting customer support, but as this appears to be official policy I would not expect a change there. I'd recommend you reach out to support@github.com, they're usually very helpful with things like this.

nielsole 9y ago
Hey John, thanks for reaching out. The individual case was resolved (found a local copy). But I find the policy worrisome for future projects. If the customer support was happy to reenable access for me, what is the point of the current policy?
- crankylinuxuser 9y ago
  That's why I've been migrating my Github/lab projects to IPFS as well. I have a few cheap VPSes I have my stuff pinned. "Cloud" (read: someone else's server) is unreliable at best, or malicious at worst like this case. The people may not be bad actors, but the tech definitely is.
  - bringtheaction 9y ago
    Would like to hear more about your git with IPFS workflow.
  - icebraining 9y ago
    How are VPSs not on someone else's server too?
kercker 9y ago
If people can get the fork back after reaching out to support@github.com, why would not GitHub resolve this issue once and for all, so that people will not need to reach out to support@github.com any more?
philipwhiuk 9y ago
If Support just do this kind of thing why not put it in the UI. It's like unlinking a fork - GitHub Support just do it on asking - but why is GitHub spending unnecessary manpower when it could just be a button in the settings saying 'Unlink'.

Arqu 9y ago

The author states that he didnt bother with support (luckily he had a local copy) so here are my 2 cents I've been in the exact same spot under very similar circumstances. What I can add is that the github support was great, we got it resolved within the working day. The repo was "deleted" to free up the private repos of my colleague but we didnt know that the fork on my account would go down with it. Its been probably a couple months till we got back to it and noticed the issue. They managed to recover the repo and unblock my fork. I just did a fresh repo and moved everything over. While it is odd behavior, if its really bad they will probably manage to get you back on your feet. Also Im not affiliated with github in any way just have some repos from student days over there. If it matters im on gitlab and google repos

newsat13 9y ago
So they keep copy of code after it's deleted?
- Sir_Substance 9y ago
  In their business-continuity backups, you'd have to assume yes. However, I would certainly be surprised if a Github support staff member went and fished out the off-site backup and mounted it to recover one missing repo. You'd hope that would require quite a few staff members to orchestrate. But in general, yeah. Most engineers don't think about deletion very hard when they start designing a system, and it's also convenient (although with GDPR possibly soon illegal, situation dependent) for auditing and research to merely flag things as deleted and not show them to the customer. As a result, true data deletion generally gets justified away as a bit inconvenient and not really desirable anyway, and almost no software company really deletes anything on demand. Best you can hope for is semi-annual data purges to reclaim disk space. If this bothers you, consider joining us in the world of self-hosting your services. Gitlab is in my opinion considerably better than Github anyway. Certainly it's worth spinning up a docker container and taking a peek around.

zimbatm 9y ago

Related to that: if a private repo is forked, the target account doesn't need a paying subscription. In that sense, it's the root repository holder that is paying for the new private repo. I'm not arguing if it's a good or bad thing, it just seems consistent in that regard.

IAmEveryone 9y ago

This seems to be an edge case, affecting only private repositories. I can see how this can make sense in that context. Can we do without the pitchforks? (pun intended)

ahnick 9y ago
It still doesn't make sense in that use case. He could have cloned it to his local machine and still had access to the code. Had he done that he could have pushed it back to github as a completely new repository thereby creating a legitimate fork. It's a silly requirement from github.

snowwrestler 9y ago

As someone who runs a bunch of private repos on Github, and hires freelancers and vendors to work on them, I like the way Github manages forks of private repos. When I end a relationship, and remove that person from my private repo, I want their fork of my code to go away too. Why? Because it's cleaner. It means there are no abandoned copies of my codebase sitting around forever forgotten in random Github accounts. I set up a private repo because I want to control access to my code. That's why a private repo is private. It also makes it harder for people to misrepresent their relationship to me later on. Sure, anyone with read access to one of my repos can pull it down and save a local copy. But that is different from logging into Github and having a fork of my repo. A Github fork looks and works differently from a local copy. This whole situation seems weird because the idea of a "private" repo is not inherent to how git was intended to work; it's something Github invented to make money. So I'm not surprised that it violates people's expectations sometimes.

fwdpropaganda 9y ago
That makes no sense to me. You're relying on people not making their forks out of github. If that strategy works at all, it's incidental and I wouldn't rely on it for anything that matters.
- sdrothrock 9y ago
  > You're relying on people not making their forks out of github. That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code."
  - fwdpropaganda 9y ago
    > That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code." No, he made two points. The first one is that this way you don't have your code in random freelancer's accounts, which I'm saying is wrong: a freelancer can take his code, and upload it back to his account. So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts, you're mistaken too. In fact if you don't believe me give me access to your private repos and lets see what happens.

deleted 9y ago

[deleted]

MattyRad 9y ago

I forked Popcorn Time when it came out, just because I was impressed with the app and I wanted to look over (and possibly modify) the code. I only forked in though, I didn't clone it locally. A week later when I had some free time to do so, same issue, my personal fork disappeared. It was mildly aggravating, but also a soft reminder to question how much trust to put into third-parties.

dspillett 9y ago
I wouldn't call it a trust issue, but a due diligence one: making sure you do enough to ensure anything you care about is safe. In this instance making sure that you understand the service you are using (including intricacies like this), or keeping an extra backup of your own (a locally cloned copy of the repo), or for proper paranoia, both of the above. No matter how much you trust github and those in positions of responsibility for the projects you interact with, if you don't know the exact details of the feature-set you can come unstuck due to operating under false impressions. Github has done nothing wrong, as that is how the service is intended to work and it is documented as such (though it would appear some of the documentation is incorrect or at least inconsistent?), but you still get an inconvenient surprise because of a misunderstanding. A little paranoia can be very useful!
- snugghash 9y ago
  I'd argue this is barely worth the time spent. You'd use at least a hundred services of this sort, with a flux of at least one a week. 2-3 hours reading up on intricacies, setting up backups for your data? It's a crazy amount of time to spend on something you dont care about - you just want it to work.
  - dspillett 9y ago
    If argue that if you care enough about the content that you'll do more than say "oh well" to yourself if it becomes inaccessible, then researching this sort of thing or (probably easier but maybe more costly in terms of bandwidth use) rigging it up to your existing backup infrastructure is the minimum effort you did make. If you don't you have no high ground from which to complain or blame others from if it going away inconveniences yourself. If you don't care about it that much, why do you keep it anyway?

masklinn 9y ago

https://blog.github.com/2015-07-02-greater-control-over-forks-of-your-private-repositories/ https://blog.github.com/2015-07-02-greater-control-over-fork...

Nokinside 9y ago

>GitHub has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. GitHub reserves the right to refuse service to anyone for any reason at any time. Companies write these "We are can do whatever" clauses to license agreements so that they can point to them and make people go away. IANAL, but EULA terms like are typically in breach with Consumer Law protections against unfair contract terms. If you are private person (consumer) paying for a service, this kind of term may be null and void.

deleted 9y ago

[deleted]

kylecordes 9y ago

Some of the strain here is around two very different meanings of the word "fork", but only a single feature with that name on GitHub: 1) When I want to contribute to a project, make some local changes and offer them back to the mainline, I fork. My fork is a pseudo-throwaway thing; it contains code that is hopefully destined either to make it back to mainline, or likely to be abandoned if mainline moves on in active development. 2) When I want to go my own way with a project, using it as a starting point for a new direction of development that may wander in a direction quite far from the original (it might get renamed, it might continue development of the original becomes abandoned, etc.), I also fork. Numerically meaning 1 is surely far more common, so it makes sense for the GitHub features and permissions etc., to optimize for that case. Meaning 2 is closer to the original idea of a fork, from open source vernacular long predating GitHub. Naming is hard, and I don't blame them for picking a single name for these two technologically similar (but socially different) scenarios.

jehlakj 9y ago
I don’t know much of the historical details, but whenever I think of a fork, I think of processes. I think that GitHub’s official definition is just a simplification of what happens as a side effect.
styfle 9y ago
I don’t think GitHub actually labels #2 as a fork, but traditionally that’s been the meaning. They just needed a word to show that the repo is not original and is tied to an upstream repo. For example, when I wanted to “fork” a project[0] that was no longer maintained and not accepting PRs, I actually had to contact GitHub to “unlink” my repo so that I my repo could be standalone and utilize all the features on GitHub (can’t remember which features off the top of my head). [0]: https://github.com/styfle/geoslack https://github.com/styfle/geoslack
- brianpan 9y ago
  I think you're right. So my conclusion is....a fork on GitHub is no fork.

jbfoo 9y ago

You might use gitlab to clone your github repos. Web interface to clone them is super easy (obviously you can do it from the console also), there is no limit to private repos (their business model seems to be charging for CI time and selling on-premise licenses). I'm not affiliated with either hosting services and I use both :)

hartator 9y ago

Hum, I would think it’s to avoid spreding of private company repositories when employees get terminated. It does make sense.

bhauer 9y ago

> Luckily I found an old local copy of my project, but this taught me not to rely on Github as only storage for code. This is the distillation. If something matters to you, you should personally take responsibility for its long-term storage. Apparently for the author, finding a true duplicate was just luck. To minimize the risk, maintain multiple copies on multiple media. Github is only one medium. The context is especially notable: this is source code and source code is (in a majority of cases) very small. Maintaining personal archives of project source is a comparatively simple and low-cost matter.

gkya 9y ago
How reliant people are on Github is puzzling. If Github somehow failed one day, many businesses and OSS projects would just fail to operate. What surprises me is that software teams in companies use it too, when just sending commits/patches around is quite easy with any VCS.
- katastic 9y ago
  Kind of like how that one NPM package took down like 14,000 other packages when someone took a DMCA request against an author's OTHER package and he just took them all down in protest--which took down their dependencies and their dependencies and ... "broke the world". https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ The code in question was like 11 lines of code (with curly and spaces!!) for calculating left-hand padding for a syntax highlighting code box.

AdmiralAsshat 9y ago

Does this apply to public repos? I have a close friend who past away a few months ago, and wanted to try to find some way to preserve all of his GH repos for his wife and children. I've locally cloned all of them, but the prospect that GH might delete all of his stuff if he fails to login for a certain amount of time or something is deeply concerning. I don't suppose GH has some kind of memorial/preservation mode the way Facebook does?

knownothing 9y ago
> Every user account and organization on GitHub can have unlimited collaborators on any number of public repositories. From: https://help.github.com/articles/github-s-billing-plans/ https://help.github.com/articles/github-s-billing-plans/ So if your friend's repositories are all public no payment is required.
icebraining 9y ago
"Inactive accounts may be renamed or removed by GitHub staff at their discretion." https://help.github.com/articles/name-squatting-policy/ https://help.github.com/articles/name-squatting-policy/ There are a few blog posts of people who got GH support to release the names of inactive accounts, though it's not clear if those accounts had any repos at all.
Avamander 9y ago
You can ask for a fork to be unlinked politely. Done that for a few times to re-enable search and etc.

gkya 9y ago

I observe that people "fork" repositories (which is basically a cheap clone rather than a fork, bad terminology there) not for having a copy of their own to work on, but more like a glorified "like/+1/star". So even with public repos, it seems quite acceptable that Github tries to deduplicate aggressively.

jrochkind1 9y ago

Apparently there's no github web UI to actually copy a repo so it's not listed as a fork, but of course git makes it quite possible, and github even provides directions, using git directly. https://help.github.com/articles/duplicating-a-repository/ https://help.github.com/articles/duplicating-a-repository/ I'm imagining a browser plugin that notices when a repo you are about to fork is private, and (or even without that) adds a 'copy' button which gives you text to copy-and-paste into your terminal to make a true copy.

peteey 9y ago

Is fork part of git? I don't see it mentioned in the official documentation: git-scm.com Fork seems like some feature cloud storage services invented.

Gaelan 9y ago
The terminology is a GitHub-and-friends thing, but the idea is at the core of git. When you clone a repository, you're creating a "fork" of the repo on your own computer. Git is a DVCS (distributed VCS), where you can make many copies/forks of a repository and freely push/pull commits between them. (As opposed to something like SVN, where the repository lives on a single server, and all commits go directly to that server without a separate "push" step.)
- chungy 9y ago
  The terminology is at least a couple decades older than GitHub has even existed, and was even mentioned somewhere by Linus in the creation of Git. Fork used to have a very negative connotation, and that was related to the difficulty required to pull one off. When you forked a project, you had to set up your own hosting, web space, issue tracker, version control system (and you probably couldn't clone and start off the upstream's VCS), and so forth. The technical barrier made it so that you only forked a project when you have severe disagreements with upstream; some of the most famous in history include EGCS from GCC, and XEmacs from Emacs. With DVCSes, including Git, much of that technical difficulty is automatically removed. Every clone can potentially be a fork (as in, a new independent project), and this was one of Linus's intentions. If forking is easy, it keeps upstream on their toes. After being adopted by DVCS hosting sites like GitHub, it turned around to being a positive term even.

nlo 9y ago

If you want a mirror of a repository, self hosted Gogs/Gitea is a great way to do this in a way that makes you unbeholden to the upstream.

greggman 9y ago

This is no different than Google Docs and many other similar services. If you share a Google Doc with someone it will show up in their list of Docs. But it is just a reference to "their" doc. If they delete the doc there's no doc to reference and your "apparent" copy of the doc (which was really just a reference) disappears. If you really wanted your own personal copy you need to make a duplicate. That duplicate will be yours not a reference to theirs. It was strange the first time I ran into it. I deleted an account. I had shared the documents with another account of mine. Then I noticed when I deleted the first account I lost access to those docs. Now I know I hadn't copied the docs I'd only had references to them. Next time I'll know to make copies if I actually want copies and not just access to another account's shared docs.

urda 9y ago

Backups, backups, backups, BACKUPS. Don't rely on GitHub being your only source location. Git is a DVCS, meaning you don't have to have a single upstream. Make sure you are pushing / mirroring to a third party (GitLab, Bitbucket, personal Git Server, etc)

kardos 9y ago
Do you know a good way to automate that?
- philipwhiuk 9y ago
  $ vi /usr/bin/gpa #!/bin/bash git push github $? git push bitbucket $? $ gpa
- fenwick67 9y ago
  a crontab script that does `git fetch` would be enough
- urda 9y ago
  You could have a cron job automatically sync repos, but right now I have my own local copies and I use GitLab's "Repository mirroring" [1] which has worked really well for me! [1] https://docs.gitlab.com/ee/workflow/repository_mirroring.html

discordianfish 9y ago

This is also simply to their per private repo pricing model. You can fork private repos with a free account. I'd just ask github support about this particular issue and I'm pretty sure they'll can either make the repo open or at least make the code available to you somehow.

EdSharkey 9y ago

So it sounds like active links between forks is intended to mirror the valid links between people/organizations that are doing business with one another. If people or organizations end their relationship, then there's a way to cutoff any secondary contributors to the codebase to have the ability to make pull requests from -and- receive code updates. At first blush, I thought, "GitHub is mean and just locking-in their paying customers forever!!" But now after reading the comments here, I think this is a very pretty way to represent the nuances of a fork relationship. If the original owners of a private codebase disappear, then it is reasonable and just that all of the forks to their code should as well. I believe it's reasonable and just because GitHub have no way to interpret _why_ the original owner dropped off and must respect their ownership by breaking the relationship.

tracker1 9y ago

On the one hand, it bugs me when I see a repo that was obviously cloned/forked from another REPO and uploaded new without the github (fork) link to the original... but upon seeing this, I many have to reconsider doing that with a few repositories. When I left a prior job, I forked and took over updates of a relatively popular open-source library under my own GH account... I'd hate to see it all disappear because someone from a former job decides to nuke the upstream repo.

curryz 9y ago

A Private Fork Is No Fork ...b-b-but muh snippet! Shame on you Github! You were supposed to babysit me! ~ T. Dipshit

HIPisTheAnswer 9y ago

And this is why I dont have a github account. One day, all those foolish users will be left hanging, crying for the dust which has replaced their code and CI. The deserve worse; they have enabled this central organization to subvert the heart of OSS. May github go down forever, along with google translate and all those other projects which have crippled our technical progress.

Ilyes512 9y ago

This really sucks... I know companies that made forks of public (opensource) repo's just to have a "backup" in case the person or organisation decides to take down the repo. This should really be fixed as I don't see ANY benefit in the current way github handles this now. People talking about giving contractor's or other third party people access to later revoke them (after they are done) thinking they wont have a copy, are just plain simple wrong. Git is decentralised and the contractor/dev will always have his code on his machine unless HE decides to delete it.