I don't think there's actually an option not to delete them, which would have made sense in this case.
Tell HN: GitHub will delete your private repo if you lose access to the original
151–160 of 294 posts
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#152Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#153Why a mail saying that something was deleted instead of a warning that something will be deleted??
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?
This is the real anti-feature. You should only be able to fork a private repo using an account that is directly managed by the organization that owns the repo. That way when you revoke access to the user they automatically lose access to the fork.
It's super weird that it's common to use the same account for work and non-work stuff on GitHub (myself included).
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#154Earlier quoted context omitted.
[flagged]
That is an awful lot of contortions you are doing here, to seemingly justify a word change that has had well-cemented meaning within the tech community since it's inception. We all know why this change exists, and why some people will attempt to persuade others of it's superiority. It is, however, just silly virtue signaling, and it's exhausting to hear and read. It would require some very irrational and underdevelop…
You should be aware that complaints about supposed virtue signaling are equally exhausting.
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#155Earlier quoted context omitted.
[flagged]
That is an awful lot of contortions you are doing here, to seemingly justify a word change that has had well-cemented meaning within the tech community since it's inception. We all know why this change exists, and why some people will attempt to persuade others of it's superiority. It is, however, just silly virtue signaling, and it's exhausting to hear and read. It would require some very irrational and underdevelop…
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#156Never 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.
Does that limit submitting PRs to the original repo somehow?
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#157I 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.
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#158Earlier quoted context omitted.
Is the "main" branch an advantage? I guess only if >50 percent of your repos use "main" branch
[flagged]
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#159Earlier quoted context omitted.
> because I sync’d them to a usb stick with gitea Just a tip: no need to use gitea if you want to replicate a git repository to somewhere else on disk/other disk. Just do something like this: mkdir /media/run/usb-drive/my-backup-repo (cd /media/run/usb-drive/my-backup-repo && git init) git remote add backup /media/run/usb-drive/my-backup-repo git push backup master And now you have a new repository at /media/run/usb-…
Gitea has a cron task that pulls-in changes on an ongoing basis. If a snapshot suffices, a once off "git push" or "git clone" works (but that's not too far off from downloading a tar ball, is it?). If you want to have a up-to-date local copies of multiple repos, a SQLite-backed Gitea instance is the simplest solution. An added bonus to using Gitea is flexibility in mirroring LFS objects, which can be sent to S3 or mi…
Agree to disagree :)
This seems like the simplest solution:
git remote set-url --add --push origin git@github.com:my-user/my-repo.git
git remote set-url --add --push origin /backups/repos/my-user/my-repo.git
Now when you push to origin, it pushes to your local backup as well, everything up to date, no external sosftware at all :)Thanks dabber for sharing this trick (https://news.ycombinator.com/item?id=34603174)
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#160I 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 leas…
> 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!!
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.