16 ms·

Tell HN: GitHub will delete your private repo if you lose access to the original

530 points by baobabKoodaa 4y ago

I was surprised to see this in my email today: > Your private repository baobabKoodaa/laaketutka-scripts (forked from futurice/how-to-get-healthy) has been deleted because you are no longer a collaborator on futurice/how-to-get-healthy. That was an MIT-licensed open source project I worked on years ago. We published the source code for everyone to use, so I certainly did not expect to lose access to it just because someone at my previous company has been doing spring cleaning at GitHub! I had a 100% legal fork of the project, and now it's gone... why? Turns out I don't even have a local copy of it anymore, so this actually caused me data loss. I'm fine with losing access to this particular codebase, I'm not using HN as customer support to regain access. I just wanted everyone to be aware that GitHub does this.

marc_abonce 4y ago
Sometimes this can also happen with public forks too. I learned this the hard way when youtube-dl was temporarily taken down.
Alex3917 4y ago
Thanks for the heads up, this is pretty nuts.
mattl 4y ago
Your fork wasn't public?
- baobabKoodaa 4y ago
  Correct.
sbierwagen 4y ago
Is futurice/how-to-get-healthy a public repo? It's not visible on https://github.com/orgs/futurice/repositories https://github.com/orgs/futurice/repositories If you fork a private repo and they remove you from the collaborators list, it's reasonable that your fork would be removed.
- baobabKoodaa 4y ago
  Well, it's not reasonable to me, but we'll just have to respectfully disagree on this.
  - IncRnd 4y ago
    It probably seems more reasonable to the people who own the repo.
    - baobabKoodaa 4y ago
      I don't think the people who removed my access had any intention of deleting private repos. It's just somebody cleaning up ex-employee access from GitHub.
      - tedunangst 4y ago
        As a non employee, how would I access this repo?
- glerk 4y ago
  The most “expected behavior” here would be to remove the fork relationship between the two repos and leave the copied repo as a plain private repo. I don’t think it is reasonable to just delete a private repo by default.
csteinbe 4y ago
This is documented at: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-...
- fragmede 4y ago
  “But the plans were on display…” “On display? I eventually had to go down to the cellar to find them.” “That’s the display department.” “With a flashlight.” “Ah, well, the lights had probably gone.” “So had the stairs.” “But look, you found the notice, didn’t you?” “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.” ― Douglas Adams, The Hitchhiker's Guide to the Galaxy
  - agolio 4y ago
    To clarify the appropriateness of this analogy: This is unexpected behaviour from Github here which may (and has, by the anecdote of OP) cause permanent data loss. Documentation is not good enough, as users should not have been expected to have read the entire documentation.
    - chrisfosterelli 4y ago
      I guess this is a question of who should have been given further information. For example, whoever at the organization deleted the repo would have been given a very clear warning screen including the number of forks that would be deleted by their action prior to them doing it. On that note, an organization admin can _directly_ delete your private fork without even deleting the source repository if they want. GitHub's permission model is fairly direct that private forks you make through your membership in an organization are more the organization's property than the forker's.
      - capableweb 4y ago
        > I guess this is a question of who should have been given further information. For example, whoever at the organization deleted the repo would have been given a very clear warning screen including the number of forks that would be deleted by their action prior to them doing it. This is exactly how it works today already. If I try to delete a private repository people have forked, I see the following: > We will also delete all 4 forks since this is a private repository. Clicking on the delete button, again: > Unexpected bad things will happen if you don’t read this! > This will also delete all 4 forks since this is a private repository. > [type name of repository]
tux3 4y ago
I think this is under the assumption of "employee has a private fork of the company repo, then leaves, employee should not keep the fork" So when "removed as a collaborator" which apparently includes the original being deleted, you lose access to the main repo and all forks, even yours. As if leaving a company.
- chrisfosterelli 4y ago
  Yeah I understand how this is unfortunate but for 99% of cases this is what you want to happen when you remove someone's access to a private codebase. It seems like this is an unusual use case that OP had an MIT-licensed open source project whose source only exists in a private repo.
  - cma 4y ago
    Is this scenario possible? - you fork a public repo - it's visibility is changed to private but you have access through the org - they delete it - you lose your fork, which was only ever of the public repo
    - kitkat_new 4y ago
      no, in this case it works as expected; "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private." https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories https://docs.github.com/en/repositories/creating-and-managin... But better be safe than sorry...
- nly 4y ago
  What's the point? You can always clone locally and push to a new repo without forking on GitHub. Repos will be unlinked and history will be intact.
  - chrisfosterelli 4y ago
    It's for the same reason that you don't leave ex-employees with access to other intellectual property. Just because they could make their own copies during their tenure doesn't mean you shouldn't try to reduce your exposure.
Dork1234 4y ago
Does it go into GitHub Desktop and remove it from your computer as well?
amelius 4y ago
Why a mail saying that something was deleted instead of a warning that something will be deleted??
- shagie 4y ago
  If you worked at a company and had a fork of a private repo that company maintained of some software... do you want employees who have left to have their access to the repos removed? or an email that says that it will be removed?
  - amelius 4y ago
    I'd prefer it if the repo was returned to the company, rather than removed.
    - shagie 4y ago
      That gets complicated. It's in (for example) my namespace. So shagie/foo.git And now you want to return it to BigOrg/foo.git - where does it go in that namespace of BigOrg? What are the permissions for who should have access to that? Who gets billed with a scheduled action runs and chews up a lot of CI credits as a parting gift? The workflows for anything other than "delete it" gets GitHub in a bit of a mess.
  - kitkat_new 4y ago
    one of many scenarios in which it is probably(!) desirable to revoke access. What about other scenarios?
  - xigoi 4y ago
    What prevents them from having the code locally?
    - shagie 4y ago
      Same nothing that prevents a person from copying it onto a USB stick before they leave. However, that's not GitHub's problem. GitHub is "told" (by removing the person's access from the repo) that they shouldn't have access to the repository or its code. It is within GitHub's ability to remove access to their fork and remove it.
zxcvbn4038 4y ago
I have a number of git repos that the original developers deleted - because I sync’d them to a usb stick with gitea. I think that is how you have to do it - never entrust a service, especially a free one, with your only copy of anything you value. If the YouTube algorithm nukes your account and all your videos, you should be ready to upload them to a new account. Same with anything else digital. My current is standard is one copy in AWS S3 which is super reliable but too pricy for daily use, and one copy in Cloudflare R2 or Backblaze B2 which might or might not be reliable (time will tell) but is hella cheap for daily use.
- no_butterscotch 4y ago
  > If the YouTube algorithm nukes your account and all your videos, you should be ready to upload them to a new account. Same with anything else digital. Do you know if this is a common occurrence? Also, I'm only a YouTube viewer and am not familiar with all the creator tools, problems, communities, etc. But would a creator really re-upload all their back-catalog if deleted? Just to try to get back to views and things?
  - ChrisMarshallNY 4y ago
    I remember someone posting an agonized screed, some time ago, about YT deleting their channel, and all the videos. Apparently, they had not kept the source/rendered originals of the videos, so it actually clobbered their business. I am a scarred, limping old coot, and have learned [the hard way] that backups are goooood.
    - tomcam 4y ago
      > I am a scarred, limping old coot That is a delightfully evocative phrase
  - tpxl 4y ago
    A few weeks ago, youtube changed their swearword policy. A creator I follow basically had to delete half their channel or risk termination.
rezonant 4y ago
I have to assume that the original repository was private when you forked it. If it was public, and then made private, then this should not happen. If the original code was "open source", then why exactly was it in a private repository? Putting "MIT licensed open source" into a private repository is not publishing that source code for the world to use. It sounds like nothing weird happened here other than this company thinking a private repository was "publishing it as open source".
- chrisfosterelli 4y ago
  It would have had to be privately forked. If you change your repository from public to private, GitHub detaches the forks and leaves them public, so a repo owner can't just delete someone's public fork.
- baobabKoodaa 4y ago
  > If the original code was "open source", then why exactly was it in a private repository? It's been too many years to remember the exact reasons, but this was not the only repo in the project. This was the "working directory" that had all kinds of random stuff that a data science project might accrue over time. Later in the project we published 3 repos which were more "cleaned up" to be potentially useful to outsiders (I use scare quotes around "cleaned up" because the codebases are still a mess, sorry). Anyway, 3 of the 4 repos appear to still be public: https://github.com/futurice/health-visualizations https://github.com/futurice/health-visualizations https://github.com/futurice/health-visualizations-front https://github.com/futurice/health-visualizations-front https://github.com/futurice/laaketutka-prereqs https://github.com/futurice/laaketutka-prereqs
- alerighi 4y ago
  Open source doesn't necessary mean that the code has to be share publicly on the internet, let alone on a GitHub repo! This is a common misconception. You can of course also decide to sell an open source software, that is have other pay you to obtain the software source code with an open source license (of course this person then can share the code, or even sell it to others legally, so it's not commonly done). I can put a MIT or even a GPL license in a private repository that I have at my company. The meaning is that I don't release the source code, tough if one of my employees wants to take it and use it he can, and he can also decide to share it with other people, or put it on a public repo. Why I don't want to put the repo public? Maybe I'm just lazy, I don't see too much value in the code, I don't want to write documentation, tests, whatever, I don't consider it of enough value, whatever, still I don't have problems with people that have access to the code that they use it, and share it if they want.
Encrypt-Keeper 4y ago
Self hosting something like Gitea and mirroring to that is a good solution to this.
bspammer 4y ago
Pretty bizarre behaviour given how easy it is to get around this. Instead of forking, just git remote set-url origin <new-remote-repo> The new remote can even still be on GitHub. So what’s the point? Anyone relying on this to retroactively remove access to source code has a false sense of security.
IncRnd 4y ago
> Your private repository baobabKoodaa/laaketutka-scripts (forked from futurice/how-to-get-healthy) has been deleted because you are no longer a collaborator on futurice/how-to-get-healthy. > and now it's gone... why? Because it was a private not a public repo.
- kitkat_new 4y ago
  so what? Private doesn't imply (common sense) that the original repository has power over any fork.
  - dboreham 4y ago
    It does, otherwise github just wouldn't allow forking private repositories. If they did allow that, and retained no control over the forked copy, now you can ride a coach and horses through the access control to a private repo by simply forking it when you have access. My guess is that forking a private repository is a feature github intended to be used where employees or contractors of an enterprise want to fork their employer's repository as part of their development activities for that employer. Github sees those forks as transitively controlled under the organization's access policies.
    - Dylan16807 4y ago
      > If they did allow that, and retained no control over the forked copy, now you can ride a coach and horses through the access control to a private repo by simply forking it when you have access. ...which you can still trivially do if you use git to make the copy. And then your github repo will be immune to this kind of deletion. So common sense says to me this should act similarly.
      - djur 4y ago
        > ...which you can still trivially do if you use git to make the copy. If you want to steal code from your former employer it's your business and your legal jeopardy. GitHub can't do anything about that. They can remove access to the copies they're storing for you, though. GitHub has a weird model where they encourage using the same account for personal and professional work, which causes this kind of ambiguity. From their perspective, there isn't a real difference between forking a private repo and making a private copy of a shared Google doc in your work account.
bastardoperator 4y ago
It's not your code or data, it's your previous employers IP and they determine who has access and who doesn't and what licenses do or don't apply. Forks have worked like this for awhile and I consider it a feature, especially in cases like this.
- baobabKoodaa 4y ago
  That's not how MIT license works
  - camsjams 4y ago
    So you're suggesting GitHub should determine the total "average" license of a private repo and determine if your fork is indeed valid or not, before revoking access.
    - camsjams 4y ago
      Instead, you might just want to reach out and ask for access or a zip file from the owners
    - baobabKoodaa 4y ago
      > So you're suggesting GitHub should determine the total "average" license of a private repo and determine if your fork is indeed valid or not, before revoking access. No, I'm not suggesting that. In fact, I didn't say anything about what GitHub should or shouldn't do. My comment related to how licenses work, not how GitHub works or should work. In particular, I was responding to this comment: > It's not your code or data, it's your previous employers IP and they determine who has access and who doesn't and what licenses do or don't apply. The claim in the above comment is incorrect. I stated that the claim is incorrect. That is unrelated to the issue of how GitHub should deal with private repo forks.
      - pavon 4y ago
        You mentioned in another post that the company only released a cleaned up version publicly. That cleaned up code which they published is clearly and unambiguously under the MIT license. Any other modifications that were made and not published (including any you made in your fork as an employee) are not automatically licensed as MIT. Your employer holds the copyright to that. They might be fine with those internal changes being released as MIT or they might not, but it is up to them.
gregwebs 4y ago
This unfortunately makes sense because it is a private repo. Even if a repo is labeled as being MIT and has an MIT license in it, it still may contain other code of a different license. Github could do better by warning the repo owner when they delete a private repo. Github could ask the repo owner if they want to convert it to public first (a "set it free" option) or otherwise give the option to avoid deleting the forks of others.
- pavon 4y ago
  Yes, and under most FLOSS licenses (including BSD/MIT/LGPL/GPL/AGPL), companies are perfectly free to maintain modified versions of the software internally with no obligation to publish the source externally, until/unless they distribute the modified software externally (or allow external use the software remotely in the case of AGPL). All of the modifications are copyright the company and it is their choice whether to release them publicly. Employees having access to the modifications doesn't mean that the modifications have been licensed to them under the original license, and thus doesn't give them permission to distribute the modified software to others under that license. Essentially what I just said is the same as what you did. The private modifications cannot be assumed to be under the same license as the original software. Gitlab has no way of knowing all these details, and have promised to keep private repos private, so their current policy is the correct one.
- kitkat_new 4y ago
  "This unfortunately makes sense because it is a private repo." I disagree. I expect a (i.e. my) fork to be independent of the original repository, no matter if it is private or not. It's enough if a fork of a private repository is private then too.
  - bcrosby95 4y ago
    This is why I don't use github's fork feature. There's more than just this restriction they impose upon you. Instead I prefer to use a "git" fork. I just clone it and upload it to my own repo. Assuming the license permits of course.
josephcsible 4y ago
Never use the fork feature on private repos. Instead, clone the repo locally, create a fresh GitHub repo, and push your local clone manually to that. Doing so will protect you from this attack.
- theossuary 4y ago
  It'd be nice to be able to manually specify an upstream for a repo, that's the main benefit of forking in the UI.
- hashtag-til 4y ago
  Does that limit submitting PRs to the original repo somehow?
  - kitkat_new 4y ago
    you need to make a fork for that, however you could add that one as a second upstream repo
  - kevincox 4y ago
    Apparently yes. You can't submit PRs to a repo outside of the "fork network". (IIUC these all share a single Git repo under the hood)
bdcravens 4y ago
I'm sorry to hear that whoever trained you on using Github didn't explain this to you.
- deleted 4y ago
  [deleted]
nobody9999 4y ago
I completely understand your frustration. It's a dick move to delete your content without (at least) giving you a chance to archive that work. At the same time this situation points up an important issue: if you don't own/control the infrastructure where your data lives, you don't own that data. Full stop. If you host your data "in the cloud" (i.e., on someone else's servers) then you don't own that data, or at least not any copies stored there). I'm not advocating for any specific action/solution in this comment (see my comment history for more about centralization vs. decentralization and "the cloud"), but the above is an important consideration, especially WRT long-term storage of your data.
- kaushikc 4y ago
  It's simple! Maintain the control and the capability to retrieve your important data at all times. The internet is a wild place and everything you don't save could potentially be gone forever.
  - nobody9999 4y ago
    >It's simple! Maintain the control and the capability to retrieve your important data at all times. An excellent point, but I'd go further and say that one should maintain multiple copies of important data, with at least one of those on hardware/infrastructure you control and have physical access to.
- ben0x539 4y ago
  > At the same time this situation points up an important issue: if you don't own/control the infrastructure where your data lives, you don't own that data. Full stop. We've known about this for many years!! And yet we for many varied reasons choose to make use of services anyway!! That doesn't mean we shouldn't get to complain about those services and giving people shit for that is really weird!!
  - nobody9999 4y ago
    >We've known about this for many years!! And yet we for many varied reasons choose to make use of services anyway!! That doesn't mean we shouldn't get to complain about those services and giving people shit for that is really weird!! I don't disagree at all. I just find it a little surprising that on a site where "not your keys, not your coins" is accepted wisdom, that "not your storage, not your data" isn't as well accepted. That said, I am biased and have an agenda: 1. The centralization of network resources is a recipe for disaster; 2. There are many factors which have pushed us toward more centralization, and most of those factors (asymmetric bandwidth on consumer internet links, abusive terms of service, e.g., port blocking/traffic throttling, crappy consumer networking gear, etc., etc., etc) rarely get addressed; 3. The issues in (2) create perverse incentives for commercial entities to further abuse their "customers" (for "free" services that should read "product"); 4. Those perverse incentives have morphed outside of paid and "free" SaaS and subscription tech services, encouraging manufacturers of all manner of products (cars, appliances, computers, communication devices and a raft of other products to employ these abusive, rent-seeking tactics as well; 5. Resolving the issues detailed in (2) (as well as those not detailed) could enable both libre and commercial self-hosting products to become a viable, profitable industry, both for products and support services. Thus enabling us (broadly, humans who use the global internet) to actually own and control our data, PII and privacy; 6. Solutions are plentiful, but the perverse incentives cut across the entire OSI stack and beyond, making the reversal of such incentives complex and difficult, especially because the hoi polloi either don't know or have been convinced that they shouldn't care about ownership (of physical products like phones, cars and appliances) of their data and PII. I don't have a comprehensive set of solutions, but creating competition (municipal last-mile broadband, interoperability requirements, etc.) and providing consumers with the tools they need to decide for themselves (symmetric bandwidth on internet links, "dumb" internet pipes, non-abusive TOS, etc.) how they should host/manage/control their data and possessions will be important steps forward in reversing such incentives. I rant about this every so often (this being my latest offering), and while it's not specific to Github or how their TOS treats various data storage offerings (repos), it's absolutely an example of how these perverse incentives harm and abuse consumers. In my view, that's wrong. Edit: Clarified my prose.
smeagull 4y ago
This destroys the very basic idea of opensource. That the first developer on a project can hand off to someone else to take over the project, and have the project continue past their involvement. Now if the first developer deletes their account or repo everything dies.
- watermelon0 4y ago
  This does not affect public repositories, so open source code should be fine.
glitchc 4y ago
Do you have a local clone? If yes, just populate a new remote with the local clone. If not, always a good idea to keep an updated clone of every remote repo. That's how git is supposed to work. The latest pull is the backup.
j45 4y ago
Looks like a gitlab.com backup of everything is mandatory.
thewellington 4y ago
I wonder if this works the other way around. - create new repo in your personal GitHub acct. - fork it to company repo. - leave company years later - revoke access to company codebase. :)
pvaldes 4y ago
Totally expected from the minute one after Microsoft buy the vault, earning full control over the software and the people's access to the platform. I will not be surprised at all if some of this closed projects would appear included into closed software under new authors after a year.
- capableweb 4y ago
  Is this behavior new? It has been like that for as long as I can remember, certainly before Microsoft bought GitHub.
  - autophagian 4y ago
    It is not. I also remember this behavior around forking private repos from before the acquisition. But then again, this doesn't lend itself to a conveniently pithy comment about Microsoft ruining everything.
bdowling 4y ago
GitHub probably does this to protect itself from potential copyright claims by the copyright owner. In most cases, copyright owners will want Github to stop distributing copies of their code to people whose access they revoked. They won't care whether the copies are in a fork or not. If Github didn't revoke access to the code, including in forked repos, then the copyright owners could send DMCA takedown notices and potentially sue Github. Processing those takes time and money, so they do the easier and cheaper thing.
Sephr 4y ago
GitHub also blocks their built-in fork UI functionality when the original repo's owner uses the site's "block" feature against you, which doesn't align with my expectations. Ironically, anyone affected by this poorly implemented blocking behavior (and thereby copying the full repo instead of forking) would be protected from this bug by the OP.
- tgsovlerkhgsel 4y ago
  According to the documentation I remember reading, blocking someone would delete their forks of your repos (including public ones) back then. I believe this is no longer the case.
- djur 4y ago
  This is because forking is a social feature. If the origin repo is unwilling to accept pull requests from you, there's no reason to let you fork.
s17n 4y ago
Same thing happened to me, it sucks. All the development had been in my fork (not just my own work, also my collaborators;) and now it's just gone. Github should change this policy.
hashtag-til 4y ago
Every day is a new joy with GitHub, these days.
HomeDeLaPot 4y ago
Try to treat YouTube, GitHub, and any other service the way you would a failing hard drive. If it's not backed up, it doesn't exist.
whstl 4y ago
I have an interesting but unrelated story about files going away in Github. Remember when Windows Research source code that was used for teaching in university, and was leaked in the late-aughts, way before Microsoft purchased Github? I had this code in one private repository called "ms" for more than a decade. It didn't have Git history or anything, it was just some random files, plus the leaked sources. I totally forgot about it until a last year ago, when I checked, and the code is entirely gone. I'm now more careful about what I put in private repos. In fact I don't have anything private there anymore...
naikrovek 4y ago
This is how GitHub has always worked, and it's been documented the entire time. Forks are not just copies of other repos which go on to get their own history (or lack thereof) from that point on. They are linked to the parent repo, and share its visibility. If the parent repo goes private, so does the fork, for example. There's a parent-child relationship that GitHub creates when you fork a repo using the "Fork" button in the UI. That is how this relationship is created. This has always been the case with the "Fork" button on github.com. This should not have surprised you.
- kitkat_new 4y ago
  "If the parent repo goes private, so does the fork, for example." not true "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private."
Vecr 4y ago
I'm not sure why people are defending Github on this issue, what if the original repo was a template or something, and your thousands of lines of code is gone because the original template repo removed you as a contributor. If I copy something, I expect where I copied it from to have exactly zero bearing on what happens to my copy. If they have a problem they can serve legal documents, giving everyone time to figure something out with zero data loss.
- theturtletalks 4y ago
  Guess I’ll be cloning repos locally and then pushing instead of forking.
  - kevincox 4y ago
    Apparently this removes you ability to open Pull Requests.
- andybak 4y ago
  I agree completely. But at the same time - who doesn't have local copies of anything they care about? What are they thinking!?
  - sshine 4y ago
    You’d be surprised at how many use GirHub as their remote code backup platform. Having private file system backups is a question of culture, and a lot don’t have it.
    - hgsgm 4y ago
      If no one has a copy of the software, does it really exist?
- rezonant 4y ago
  This only applies to private repositories. Do not put templates up as private repositories, and do not use forks when consuming templates. That is not what forks are for.
sangnoir 4y ago
If you have a Raspberry Pi wasting away in a drawer[0], I strongly recommend installing Gitea or Forgejo and mirroring all the repos you like (i.e. the ones you contribute(d) to and/or starred, not just on Github too!). You set it up once and it will sync in upstream changes as often as you like (default is daily) 0. Or a homelab, or a cheap 256MB VM, or a NAS that can run docker containers, or an old Chromebook: anything that can execute a Go binary, x64, arm6 or even mips
- kitkat_new 4y ago
  I'll look for a tool that mirrors all my repositories (i.e. only forks). If I can't find one, I'll write it myself.
  - jmondi 4y ago
    I wrote a little tool to mirror my repositories to my gitea instance. It has been months to potentially a year or two since I ran this, but it does what you’re asking. You can mirror repositories of users and repos users have starred. It definitely needs some love. https://github.com/jasonraimondi/deno-mirror-to-gitea https://github.com/jasonraimondi/deno-mirror-to-gitea
    - mckn1ght 4y ago
      I wrote a similar one I called Forgery that’s in a repo of the same name in my github account (which can be found in my user profile… just created this account and didn’t want to post a link in my first post, thought it might get automodded). Very similar to yours, but also does forks, which I’m not sure yours does by a quick glance at your readme. Although, mine doesn’t automatically mirror from another forge, just clones everything locally. I’ll have to add a TODO to add mirroring. Please have a look at how I handle them and consider adding a link to my project in your “similar tools” section, and I’ll do the same for you!
      - jmondi 4y ago
        If I remember correctly, I believe that mine will do forks also, they are just included in in your repositories. I just looked over your project, and it seems pretty cool. A little bit different than mine, since mine is specifically github to a gitea mirror repository. I don't mind adding a link to your project in mine. Thanks for sharing!
tuxracer 4y ago
Recently setup Forgejo and it's been working out great as a self-hosted GitHub alternative. Once we have cross-domain pull requests and comments (wip) these alternatives can hopefully really take off.
oever 4y ago
You can send the code to the Software Heritage: https://archive.softwareheritage.org/save/ https://archive.softwareheritage.org/save/ Perhaps there's a userscript to send everything that you fork there. Ideally, federated forges will become more widely used: then a fork would mean copying the code to a forge of your choosing and there is less risk of losing code.
ajb 4y ago
It's with noting that the person doing the Spring Cleaning would have been warned that they were about to delete your forks. They could have contacted you to mention this I don't think there's actually an option not to delete them, which would have made sense in this case.
jacobsenscott 4y ago
I bet github is used as much or more for proprietary corporate development as it is used for open source development. This is the right choice for paying customers.
OJFord 4y ago
> That was an MIT-licensed open source project I wonder if perhaps they made it private before deleting it. It would make sense perhaps for GitHub to do this if the original was private and you lost access to it (though.. you should still somehow retain downstream work?) - and I can easily imagine that coming with a 'checking private status at time of delete not time of fork' bug.
dom96 4y ago
I'm getting a sense like something is not right at GitHub, maybe it's just a coincidence but just in the last week I saw GitHub breaking their CI (causing many runs to fail due to a billing bug), then the checksum tarball issue and now this.
- djur 4y ago
  This is how private forks have worked at GitHub forever.
  - deleted 4y ago
    [deleted]
yieldcrv 4y ago
> Turns out I don't even have a local copy of it anymore Looks like you'll never do that again
karmaMeansCool 4y ago
This is why I never fork a repo from github. I checkout my own branch (like git is supposed to be) and create a repo on github and most importantly, another server.
Jorengarenar 4y ago
We ought to treat GitHub's "fork" more like "branch on my account". If one wants to create an actual fork, then clone the repository locally, change the upstream and push to repo on your account.
barco 4y ago
Given the nature of super forks in GitHub, if you are no longer a contributor, but keep your fork, you would be able to see the commits that happen in the original repo and all its forks. There used to be a way to bypass the deletion, which was to clone into a organization. That way, GitHub would not delete your fork. I am not sure if it is still the case. I reported all this to GitHub a few years ago, but they said it was a non-issue .
deleted 4y ago
[deleted]
phendrenad2 4y ago
Seems like it's working as intended. The code is MIT-licensed, but github doesn't know that. It only knows that you were allowed access to a private repo, and that access was revoked. This is supposed to save you the trouble of going through all of your forks and ensuring that you aren't retaining any code from an organization you left. Personally I make new github accounts for every new org I join, but that's just me.
deleted 4y ago
[deleted]
jakeogh 4y ago
Anyone know why github search seems to be broken? While logged in, if I query https://github.com/yt-dlp/yt-dlp/search?q=exec_cmd https://github.com/yt-dlp/yt-dlp/search?q=exec_cmd no results are returned for any category. But "exec_cmd" exists in a few places in that repo, for example: https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/options.py#L1630 https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/options.... On another note... It's a honest question to ask, does github state anywhere a policy on shadowbanning (treating a repo differently in any way)? It's becoming a law of tech nature that any org big enough starts to do it. Some variation of a warrantcanary (preferably in the form of a contract with the users "we have not done X Y Z") would be cool.
btfo 4y ago
You deserve it. This is what you get for using proprietary software and not hosting your own gitea/gitlab. The repository was never yours.
- Boltgolt 4y ago
  You don't think "you deserve it" is a little harsh?
dotancohen 4y ago
Anything not on your machine - or requiring phoning home - is not yours. We saw this with the Heroku being discussed yesterday, we've seen it with Github before. Want to keep it? Store it locally.
joshxyz 4y ago
Had this happen to us before. Tradingview's JavaScript SDK is in an invite-only private repository in GitHub. We forked it, made our specific changes, then lost it once the Tradingview team removed our access after weeks of them trying to sell us stuff and not closing any sales from us. The private fork we had, with our numerous changes, all gone.
hgsgm 4y ago
> We published the source code for everyone to use, Published it where? If it's published, how did you lose access to the software, even if the fork is gone?
Dr_ReD 4y ago
This is the typical boneheaded, executive-mandated, policy. Once they get enough backlash they'll probably backtrack.
deleted 4y ago
[deleted]

530 points by baobabKoodaa 4y ago

marc_abonce 4y ago

Sometimes this can also happen with public forks too. I learned this the hard way when youtube-dl was temporarily taken down.

Alex3917 4y ago

Thanks for the heads up, this is pretty nuts.

mattl 4y ago

Your fork wasn't public?

baobabKoodaa 4y ago
Correct.

sbierwagen 4y ago

Is futurice/how-to-get-healthy a public repo? It's not visible on https://github.com/orgs/futurice/repositories https://github.com/orgs/futurice/repositories If you fork a private repo and they remove you from the collaborators list, it's reasonable that your fork would be removed.

baobabKoodaa 4y ago
Well, it's not reasonable to me, but we'll just have to respectfully disagree on this.
- IncRnd 4y ago
  It probably seems more reasonable to the people who own the repo.
  - baobabKoodaa 4y ago
    I don't think the people who removed my access had any intention of deleting private repos. It's just somebody cleaning up ex-employee access from GitHub.
    - tedunangst 4y ago
      As a non employee, how would I access this repo?
glerk 4y ago
The most “expected behavior” here would be to remove the fork relationship between the two repos and leave the copied repo as a plain private repo. I don’t think it is reasonable to just delete a private repo by default.

csteinbe 4y ago

This is documented at: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-...

fragmede 4y ago
“But the plans were on display…” “On display? I eventually had to go down to the cellar to find them.” “That’s the display department.” “With a flashlight.” “Ah, well, the lights had probably gone.” “So had the stairs.” “But look, you found the notice, didn’t you?” “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.” ― Douglas Adams, The Hitchhiker's Guide to the Galaxy
- agolio 4y ago
  To clarify the appropriateness of this analogy: This is unexpected behaviour from Github here which may (and has, by the anecdote of OP) cause permanent data loss. Documentation is not good enough, as users should not have been expected to have read the entire documentation.
  - chrisfosterelli 4y ago
    I guess this is a question of who should have been given further information. For example, whoever at the organization deleted the repo would have been given a very clear warning screen including the number of forks that would be deleted by their action prior to them doing it. On that note, an organization admin can _directly_ delete your private fork without even deleting the source repository if they want. GitHub's permission model is fairly direct that private forks you make through your membership in an organization are more the organization's property than the forker's.
    - capableweb 4y ago
      > I guess this is a question of who should have been given further information. For example, whoever at the organization deleted the repo would have been given a very clear warning screen including the number of forks that would be deleted by their action prior to them doing it. This is exactly how it works today already. If I try to delete a private repository people have forked, I see the following: > We will also delete all 4 forks since this is a private repository. Clicking on the delete button, again: > Unexpected bad things will happen if you don’t read this! > This will also delete all 4 forks since this is a private repository. > [type name of repository]

tux3 4y ago

I think this is under the assumption of "employee has a private fork of the company repo, then leaves, employee should not keep the fork" So when "removed as a collaborator" which apparently includes the original being deleted, you lose access to the main repo and all forks, even yours. As if leaving a company.

chrisfosterelli 4y ago
Yeah I understand how this is unfortunate but for 99% of cases this is what you want to happen when you remove someone's access to a private codebase. It seems like this is an unusual use case that OP had an MIT-licensed open source project whose source only exists in a private repo.
- cma 4y ago
  Is this scenario possible? - you fork a public repo - it's visibility is changed to private but you have access through the org - they delete it - you lose your fork, which was only ever of the public repo
  - kitkat_new 4y ago
    no, in this case it works as expected; "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private." https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories https://docs.github.com/en/repositories/creating-and-managin... But better be safe than sorry...
nly 4y ago
What's the point? You can always clone locally and push to a new repo without forking on GitHub. Repos will be unlinked and history will be intact.
- chrisfosterelli 4y ago
  It's for the same reason that you don't leave ex-employees with access to other intellectual property. Just because they could make their own copies during their tenure doesn't mean you shouldn't try to reduce your exposure.

Dork1234 4y ago

Does it go into GitHub Desktop and remove it from your computer as well?

amelius 4y ago

Why a mail saying that something was deleted instead of a warning that something will be deleted??

shagie 4y ago
If you worked at a company and had a fork of a private repo that company maintained of some software... do you want employees who have left to have their access to the repos removed? or an email that says that it will be removed?
- amelius 4y ago
  I'd prefer it if the repo was returned to the company, rather than removed.
  - shagie 4y ago
    That gets complicated. It's in (for example) my namespace. So shagie/foo.git And now you want to return it to BigOrg/foo.git - where does it go in that namespace of BigOrg? What are the permissions for who should have access to that? Who gets billed with a scheduled action runs and chews up a lot of CI credits as a parting gift? The workflows for anything other than "delete it" gets GitHub in a bit of a mess.
- kitkat_new 4y ago
  one of many scenarios in which it is probably(!) desirable to revoke access. What about other scenarios?
- xigoi 4y ago
  What prevents them from having the code locally?
  - shagie 4y ago
    Same nothing that prevents a person from copying it onto a USB stick before they leave. However, that's not GitHub's problem. GitHub is "told" (by removing the person's access from the repo) that they shouldn't have access to the repository or its code. It is within GitHub's ability to remove access to their fork and remove it.

zxcvbn4038 4y ago

I have a number of git repos that the original developers deleted - because I sync’d them to a usb stick with gitea. I think that is how you have to do it - never entrust a service, especially a free one, with your only copy of anything you value. If the YouTube algorithm nukes your account and all your videos, you should be ready to upload them to a new account. Same with anything else digital. My current is standard is one copy in AWS S3 which is super reliable but too pricy for daily use, and one copy in Cloudflare R2 or Backblaze B2 which might or might not be reliable (time will tell) but is hella cheap for daily use.

no_butterscotch 4y ago
> If the YouTube algorithm nukes your account and all your videos, you should be ready to upload them to a new account. Same with anything else digital. Do you know if this is a common occurrence? Also, I'm only a YouTube viewer and am not familiar with all the creator tools, problems, communities, etc. But would a creator really re-upload all their back-catalog if deleted? Just to try to get back to views and things?
- ChrisMarshallNY 4y ago
  I remember someone posting an agonized screed, some time ago, about YT deleting their channel, and all the videos. Apparently, they had not kept the source/rendered originals of the videos, so it actually clobbered their business. I am a scarred, limping old coot, and have learned [the hard way] that backups are goooood.
  - tomcam 4y ago
    > I am a scarred, limping old coot That is a delightfully evocative phrase
- tpxl 4y ago
  A few weeks ago, youtube changed their swearword policy. A creator I follow basically had to delete half their channel or risk termination.

rezonant 4y ago

I have to assume that the original repository was private when you forked it. If it was public, and then made private, then this should not happen. If the original code was "open source", then why exactly was it in a private repository? Putting "MIT licensed open source" into a private repository is not publishing that source code for the world to use. It sounds like nothing weird happened here other than this company thinking a private repository was "publishing it as open source".

chrisfosterelli 4y ago
It would have had to be privately forked. If you change your repository from public to private, GitHub detaches the forks and leaves them public, so a repo owner can't just delete someone's public fork.
baobabKoodaa 4y ago
> If the original code was "open source", then why exactly was it in a private repository? It's been too many years to remember the exact reasons, but this was not the only repo in the project. This was the "working directory" that had all kinds of random stuff that a data science project might accrue over time. Later in the project we published 3 repos which were more "cleaned up" to be potentially useful to outsiders (I use scare quotes around "cleaned up" because the codebases are still a mess, sorry). Anyway, 3 of the 4 repos appear to still be public: https://github.com/futurice/health-visualizations https://github.com/futurice/health-visualizations https://github.com/futurice/health-visualizations-front https://github.com/futurice/health-visualizations-front https://github.com/futurice/laaketutka-prereqs https://github.com/futurice/laaketutka-prereqs
alerighi 4y ago
Open source doesn't necessary mean that the code has to be share publicly on the internet, let alone on a GitHub repo! This is a common misconception. You can of course also decide to sell an open source software, that is have other pay you to obtain the software source code with an open source license (of course this person then can share the code, or even sell it to others legally, so it's not commonly done). I can put a MIT or even a GPL license in a private repository that I have at my company. The meaning is that I don't release the source code, tough if one of my employees wants to take it and use it he can, and he can also decide to share it with other people, or put it on a public repo. Why I don't want to put the repo public? Maybe I'm just lazy, I don't see too much value in the code, I don't want to write documentation, tests, whatever, I don't consider it of enough value, whatever, still I don't have problems with people that have access to the code that they use it, and share it if they want.

Encrypt-Keeper 4y ago

Self hosting something like Gitea and mirroring to that is a good solution to this.

bspammer 4y ago

Pretty bizarre behaviour given how easy it is to get around this. Instead of forking, just git remote set-url origin <new-remote-repo> The new remote can even still be on GitHub. So what’s the point? Anyone relying on this to retroactively remove access to source code has a false sense of security.

IncRnd 4y ago

> Your private repository baobabKoodaa/laaketutka-scripts (forked from futurice/how-to-get-healthy) has been deleted because you are no longer a collaborator on futurice/how-to-get-healthy. > and now it's gone... why? Because it was a private not a public repo.

kitkat_new 4y ago
so what? Private doesn't imply (common sense) that the original repository has power over any fork.
- dboreham 4y ago
  It does, otherwise github just wouldn't allow forking private repositories. If they did allow that, and retained no control over the forked copy, now you can ride a coach and horses through the access control to a private repo by simply forking it when you have access. My guess is that forking a private repository is a feature github intended to be used where employees or contractors of an enterprise want to fork their employer's repository as part of their development activities for that employer. Github sees those forks as transitively controlled under the organization's access policies.
  - Dylan16807 4y ago
    > If they did allow that, and retained no control over the forked copy, now you can ride a coach and horses through the access control to a private repo by simply forking it when you have access. ...which you can still trivially do if you use git to make the copy. And then your github repo will be immune to this kind of deletion. So common sense says to me this should act similarly.
    - djur 4y ago
      > ...which you can still trivially do if you use git to make the copy. If you want to steal code from your former employer it's your business and your legal jeopardy. GitHub can't do anything about that. They can remove access to the copies they're storing for you, though. GitHub has a weird model where they encourage using the same account for personal and professional work, which causes this kind of ambiguity. From their perspective, there isn't a real difference between forking a private repo and making a private copy of a shared Google doc in your work account.

bastardoperator 4y ago

It's not your code or data, it's your previous employers IP and they determine who has access and who doesn't and what licenses do or don't apply. Forks have worked like this for awhile and I consider it a feature, especially in cases like this.

baobabKoodaa 4y ago
That's not how MIT license works
- camsjams 4y ago
  So you're suggesting GitHub should determine the total "average" license of a private repo and determine if your fork is indeed valid or not, before revoking access.
  - camsjams 4y ago
    Instead, you might just want to reach out and ask for access or a zip file from the owners
  - baobabKoodaa 4y ago
    > So you're suggesting GitHub should determine the total "average" license of a private repo and determine if your fork is indeed valid or not, before revoking access. No, I'm not suggesting that. In fact, I didn't say anything about what GitHub should or shouldn't do. My comment related to how licenses work, not how GitHub works or should work. In particular, I was responding to this comment: > It's not your code or data, it's your previous employers IP and they determine who has access and who doesn't and what licenses do or don't apply. The claim in the above comment is incorrect. I stated that the claim is incorrect. That is unrelated to the issue of how GitHub should deal with private repo forks.
    - pavon 4y ago
      You mentioned in another post that the company only released a cleaned up version publicly. That cleaned up code which they published is clearly and unambiguously under the MIT license. Any other modifications that were made and not published (including any you made in your fork as an employee) are not automatically licensed as MIT. Your employer holds the copyright to that. They might be fine with those internal changes being released as MIT or they might not, but it is up to them.

gregwebs 4y ago

This unfortunately makes sense because it is a private repo. Even if a repo is labeled as being MIT and has an MIT license in it, it still may contain other code of a different license. Github could do better by warning the repo owner when they delete a private repo. Github could ask the repo owner if they want to convert it to public first (a "set it free" option) or otherwise give the option to avoid deleting the forks of others.

pavon 4y ago
Yes, and under most FLOSS licenses (including BSD/MIT/LGPL/GPL/AGPL), companies are perfectly free to maintain modified versions of the software internally with no obligation to publish the source externally, until/unless they distribute the modified software externally (or allow external use the software remotely in the case of AGPL). All of the modifications are copyright the company and it is their choice whether to release them publicly. Employees having access to the modifications doesn't mean that the modifications have been licensed to them under the original license, and thus doesn't give them permission to distribute the modified software to others under that license. Essentially what I just said is the same as what you did. The private modifications cannot be assumed to be under the same license as the original software. Gitlab has no way of knowing all these details, and have promised to keep private repos private, so their current policy is the correct one.
kitkat_new 4y ago
"This unfortunately makes sense because it is a private repo." I disagree. I expect a (i.e. my) fork to be independent of the original repository, no matter if it is private or not. It's enough if a fork of a private repository is private then too.
- bcrosby95 4y ago
  This is why I don't use github's fork feature. There's more than just this restriction they impose upon you. Instead I prefer to use a "git" fork. I just clone it and upload it to my own repo. Assuming the license permits of course.

josephcsible 4y ago

Never use the fork feature on private repos. Instead, clone the repo locally, create a fresh GitHub repo, and push your local clone manually to that. Doing so will protect you from this attack.

theossuary 4y ago
It'd be nice to be able to manually specify an upstream for a repo, that's the main benefit of forking in the UI.
hashtag-til 4y ago
Does that limit submitting PRs to the original repo somehow?
- kitkat_new 4y ago
  you need to make a fork for that, however you could add that one as a second upstream repo
- kevincox 4y ago
  Apparently yes. You can't submit PRs to a repo outside of the "fork network". (IIUC these all share a single Git repo under the hood)

bdcravens 4y ago

I'm sorry to hear that whoever trained you on using Github didn't explain this to you.

deleted 4y ago
[deleted]

nobody9999 4y ago

I completely understand your frustration. It's a dick move to delete your content without (at least) giving you a chance to archive that work. At the same time this situation points up an important issue: if you don't own/control the infrastructure where your data lives, you don't own that data. Full stop. If you host your data "in the cloud" (i.e., on someone else's servers) then you don't own that data, or at least not any copies stored there). I'm not advocating for any specific action/solution in this comment (see my comment history for more about centralization vs. decentralization and "the cloud"), but the above is an important consideration, especially WRT long-term storage of your data.

kaushikc 4y ago
It's simple! Maintain the control and the capability to retrieve your important data at all times. The internet is a wild place and everything you don't save could potentially be gone forever.
- nobody9999 4y ago
  >It's simple! Maintain the control and the capability to retrieve your important data at all times. An excellent point, but I'd go further and say that one should maintain multiple copies of important data, with at least one of those on hardware/infrastructure you control and have physical access to.
ben0x539 4y ago
> At the same time this situation points up an important issue: if you don't own/control the infrastructure where your data lives, you don't own that data. Full stop. We've known about this for many years!! And yet we for many varied reasons choose to make use of services anyway!! That doesn't mean we shouldn't get to complain about those services and giving people shit for that is really weird!!
- nobody9999 4y ago
  >We've known about this for many years!! And yet we for many varied reasons choose to make use of services anyway!! That doesn't mean we shouldn't get to complain about those services and giving people shit for that is really weird!! I don't disagree at all. I just find it a little surprising that on a site where "not your keys, not your coins" is accepted wisdom, that "not your storage, not your data" isn't as well accepted. That said, I am biased and have an agenda: 1. The centralization of network resources is a recipe for disaster; 2. There are many factors which have pushed us toward more centralization, and most of those factors (asymmetric bandwidth on consumer internet links, abusive terms of service, e.g., port blocking/traffic throttling, crappy consumer networking gear, etc., etc., etc) rarely get addressed; 3. The issues in (2) create perverse incentives for commercial entities to further abuse their "customers" (for "free" services that should read "product"); 4. Those perverse incentives have morphed outside of paid and "free" SaaS and subscription tech services, encouraging manufacturers of all manner of products (cars, appliances, computers, communication devices and a raft of other products to employ these abusive, rent-seeking tactics as well; 5. Resolving the issues detailed in (2) (as well as those not detailed) could enable both libre and commercial self-hosting products to become a viable, profitable industry, both for products and support services. Thus enabling us (broadly, humans who use the global internet) to actually own and control our data, PII and privacy; 6. Solutions are plentiful, but the perverse incentives cut across the entire OSI stack and beyond, making the reversal of such incentives complex and difficult, especially because the hoi polloi either don't know or have been convinced that they shouldn't care about ownership (of physical products like phones, cars and appliances) of their data and PII. I don't have a comprehensive set of solutions, but creating competition (municipal last-mile broadband, interoperability requirements, etc.) and providing consumers with the tools they need to decide for themselves (symmetric bandwidth on internet links, "dumb" internet pipes, non-abusive TOS, etc.) how they should host/manage/control their data and possessions will be important steps forward in reversing such incentives. I rant about this every so often (this being my latest offering), and while it's not specific to Github or how their TOS treats various data storage offerings (repos), it's absolutely an example of how these perverse incentives harm and abuse consumers. In my view, that's wrong. Edit: Clarified my prose.

smeagull 4y ago

This destroys the very basic idea of opensource. That the first developer on a project can hand off to someone else to take over the project, and have the project continue past their involvement. Now if the first developer deletes their account or repo everything dies.

watermelon0 4y ago
This does not affect public repositories, so open source code should be fine.

glitchc 4y ago

Do you have a local clone? If yes, just populate a new remote with the local clone. If not, always a good idea to keep an updated clone of every remote repo. That's how git is supposed to work. The latest pull is the backup.

j45 4y ago

Looks like a gitlab.com backup of everything is mandatory.

thewellington 4y ago

I wonder if this works the other way around. - create new repo in your personal GitHub acct. - fork it to company repo. - leave company years later - revoke access to company codebase. :)

pvaldes 4y ago

Totally expected from the minute one after Microsoft buy the vault, earning full control over the software and the people's access to the platform. I will not be surprised at all if some of this closed projects would appear included into closed software under new authors after a year.

capableweb 4y ago
Is this behavior new? It has been like that for as long as I can remember, certainly before Microsoft bought GitHub.
- autophagian 4y ago
  It is not. I also remember this behavior around forking private repos from before the acquisition. But then again, this doesn't lend itself to a conveniently pithy comment about Microsoft ruining everything.

bdowling 4y ago

GitHub probably does this to protect itself from potential copyright claims by the copyright owner. In most cases, copyright owners will want Github to stop distributing copies of their code to people whose access they revoked. They won't care whether the copies are in a fork or not. If Github didn't revoke access to the code, including in forked repos, then the copyright owners could send DMCA takedown notices and potentially sue Github. Processing those takes time and money, so they do the easier and cheaper thing.

Sephr 4y ago

GitHub also blocks their built-in fork UI functionality when the original repo's owner uses the site's "block" feature against you, which doesn't align with my expectations. Ironically, anyone affected by this poorly implemented blocking behavior (and thereby copying the full repo instead of forking) would be protected from this bug by the OP.

tgsovlerkhgsel 4y ago
According to the documentation I remember reading, blocking someone would delete their forks of your repos (including public ones) back then. I believe this is no longer the case.
djur 4y ago
This is because forking is a social feature. If the origin repo is unwilling to accept pull requests from you, there's no reason to let you fork.

s17n 4y ago

Same thing happened to me, it sucks. All the development had been in my fork (not just my own work, also my collaborators;) and now it's just gone. Github should change this policy.

hashtag-til 4y ago

Every day is a new joy with GitHub, these days.

HomeDeLaPot 4y ago

Try to treat YouTube, GitHub, and any other service the way you would a failing hard drive. If it's not backed up, it doesn't exist.

whstl 4y ago

I have an interesting but unrelated story about files going away in Github. Remember when Windows Research source code that was used for teaching in university, and was leaked in the late-aughts, way before Microsoft purchased Github? I had this code in one private repository called "ms" for more than a decade. It didn't have Git history or anything, it was just some random files, plus the leaked sources. I totally forgot about it until a last year ago, when I checked, and the code is entirely gone. I'm now more careful about what I put in private repos. In fact I don't have anything private there anymore...

naikrovek 4y ago

This is how GitHub has always worked, and it's been documented the entire time. Forks are not just copies of other repos which go on to get their own history (or lack thereof) from that point on. They are linked to the parent repo, and share its visibility. If the parent repo goes private, so does the fork, for example. There's a parent-child relationship that GitHub creates when you fork a repo using the "Fork" button in the UI. That is how this relationship is created. This has always been the case with the "Fork" button on github.com. This should not have surprised you.

kitkat_new 4y ago
"If the parent repo goes private, so does the fork, for example." not true "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private."

Vecr 4y ago

I'm not sure why people are defending Github on this issue, what if the original repo was a template or something, and your thousands of lines of code is gone because the original template repo removed you as a contributor. If I copy something, I expect where I copied it from to have exactly zero bearing on what happens to my copy. If they have a problem they can serve legal documents, giving everyone time to figure something out with zero data loss.

theturtletalks 4y ago
Guess I’ll be cloning repos locally and then pushing instead of forking.
- kevincox 4y ago
  Apparently this removes you ability to open Pull Requests.
andybak 4y ago
I agree completely. But at the same time - who doesn't have local copies of anything they care about? What are they thinking!?
- sshine 4y ago
  You’d be surprised at how many use GirHub as their remote code backup platform. Having private file system backups is a question of culture, and a lot don’t have it.
  - hgsgm 4y ago
    If no one has a copy of the software, does it really exist?
rezonant 4y ago
This only applies to private repositories. Do not put templates up as private repositories, and do not use forks when consuming templates. That is not what forks are for.

sangnoir 4y ago

If you have a Raspberry Pi wasting away in a drawer[0], I strongly recommend installing Gitea or Forgejo and mirroring all the repos you like (i.e. the ones you contribute(d) to and/or starred, not just on Github too!). You set it up once and it will sync in upstream changes as often as you like (default is daily) 0. Or a homelab, or a cheap 256MB VM, or a NAS that can run docker containers, or an old Chromebook: anything that can execute a Go binary, x64, arm6 or even mips

kitkat_new 4y ago
I'll look for a tool that mirrors all my repositories (i.e. only forks). If I can't find one, I'll write it myself.
- jmondi 4y ago
  I wrote a little tool to mirror my repositories to my gitea instance. It has been months to potentially a year or two since I ran this, but it does what you’re asking. You can mirror repositories of users and repos users have starred. It definitely needs some love. https://github.com/jasonraimondi/deno-mirror-to-gitea https://github.com/jasonraimondi/deno-mirror-to-gitea
  - mckn1ght 4y ago
    I wrote a similar one I called Forgery that’s in a repo of the same name in my github account (which can be found in my user profile… just created this account and didn’t want to post a link in my first post, thought it might get automodded). Very similar to yours, but also does forks, which I’m not sure yours does by a quick glance at your readme. Although, mine doesn’t automatically mirror from another forge, just clones everything locally. I’ll have to add a TODO to add mirroring. Please have a look at how I handle them and consider adding a link to my project in your “similar tools” section, and I’ll do the same for you!
    - jmondi 4y ago
      If I remember correctly, I believe that mine will do forks also, they are just included in in your repositories. I just looked over your project, and it seems pretty cool. A little bit different than mine, since mine is specifically github to a gitea mirror repository. I don't mind adding a link to your project in mine. Thanks for sharing!

tuxracer 4y ago

Recently setup Forgejo and it's been working out great as a self-hosted GitHub alternative. Once we have cross-domain pull requests and comments (wip) these alternatives can hopefully really take off.

oever 4y ago

You can send the code to the Software Heritage: https://archive.softwareheritage.org/save/ https://archive.softwareheritage.org/save/ Perhaps there's a userscript to send everything that you fork there. Ideally, federated forges will become more widely used: then a fork would mean copying the code to a forge of your choosing and there is less risk of losing code.

ajb 4y ago

It's with noting that the person doing the Spring Cleaning would have been warned that they were about to delete your forks. They could have contacted you to mention this I don't think there's actually an option not to delete them, which would have made sense in this case.

jacobsenscott 4y ago

I bet github is used as much or more for proprietary corporate development as it is used for open source development. This is the right choice for paying customers.

OJFord 4y ago

> That was an MIT-licensed open source project I wonder if perhaps they made it private before deleting it. It would make sense perhaps for GitHub to do this if the original was private and you lost access to it (though.. you should still somehow retain downstream work?) - and I can easily imagine that coming with a 'checking private status at time of delete not time of fork' bug.

dom96 4y ago

I'm getting a sense like something is not right at GitHub, maybe it's just a coincidence but just in the last week I saw GitHub breaking their CI (causing many runs to fail due to a billing bug), then the checksum tarball issue and now this.

djur 4y ago
This is how private forks have worked at GitHub forever.
- deleted 4y ago
  [deleted]

yieldcrv 4y ago

> Turns out I don't even have a local copy of it anymore Looks like you'll never do that again

karmaMeansCool 4y ago

This is why I never fork a repo from github. I checkout my own branch (like git is supposed to be) and create a repo on github and most importantly, another server.

Jorengarenar 4y ago

We ought to treat GitHub's "fork" more like "branch on my account". If one wants to create an actual fork, then clone the repository locally, change the upstream and push to repo on your account.

barco 4y ago

Given the nature of super forks in GitHub, if you are no longer a contributor, but keep your fork, you would be able to see the commits that happen in the original repo and all its forks. There used to be a way to bypass the deletion, which was to clone into a organization. That way, GitHub would not delete your fork. I am not sure if it is still the case. I reported all this to GitHub a few years ago, but they said it was a non-issue .

deleted 4y ago

[deleted]

phendrenad2 4y ago

Seems like it's working as intended. The code is MIT-licensed, but github doesn't know that. It only knows that you were allowed access to a private repo, and that access was revoked. This is supposed to save you the trouble of going through all of your forks and ensuring that you aren't retaining any code from an organization you left. Personally I make new github accounts for every new org I join, but that's just me.

deleted 4y ago

[deleted]

jakeogh 4y ago

Anyone know why github search seems to be broken? While logged in, if I query https://github.com/yt-dlp/yt-dlp/search?q=exec_cmd https://github.com/yt-dlp/yt-dlp/search?q=exec_cmd no results are returned for any category. But "exec_cmd" exists in a few places in that repo, for example: https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/options.py#L1630 https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/options.... On another note... It's a honest question to ask, does github state anywhere a policy on shadowbanning (treating a repo differently in any way)? It's becoming a law of tech nature that any org big enough starts to do it. Some variation of a warrantcanary (preferably in the form of a contract with the users "we have not done X Y Z") would be cool.

btfo 4y ago

You deserve it. This is what you get for using proprietary software and not hosting your own gitea/gitlab. The repository was never yours.

Boltgolt 4y ago
You don't think "you deserve it" is a little harsh?

dotancohen 4y ago

Anything not on your machine - or requiring phoning home - is not yours. We saw this with the Heroku being discussed yesterday, we've seen it with Github before. Want to keep it? Store it locally.

joshxyz 4y ago

Had this happen to us before. Tradingview's JavaScript SDK is in an invite-only private repository in GitHub. We forked it, made our specific changes, then lost it once the Tradingview team removed our access after weeks of them trying to sell us stuff and not closing any sales from us. The private fork we had, with our numerous changes, all gone.

hgsgm 4y ago

> We published the source code for everyone to use, Published it where? If it's published, how did you lose access to the software, even if the fork is gone?

Dr_ReD 4y ago

This is the typical boneheaded, executive-mandated, policy. Once they get enough backlash they'll probably backtrack.

deleted 4y ago

[deleted]