Live data from Hacker News

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

news.ycombinator.com

181–190 of 294 posts

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

#181
post #107

Earlier quoted context omitted.

This doesn’t make any sense to me. My private forks are * mine* and I most certainly do not want GitHub guessing at whether and when to permanently delete them without my consent. Companies of course have the right to manage access to their proprietary source code, for example by only giving access to corporate accounts under their control and reclaiming those accounts when an employee leaves.

> My private forks are mine Not if you create them using the "Fork" button in the UI. Since this behavior has yet again surprised many people, here is the documentation: https://docs.github.com/en/pull-requests/collaborating-with-...

Which also shows the right way to delete a private repo if you want people to be able to keep their forks:

If a private repository is made public, each of its private forks is turned into a standalone private repository and becomes the upstream of its own new repository network. Private forks are never automatically made public because they could contain sensitive commits that shouldn't be exposed publicly.

If a private repository is made public and then deleted, its private forks will continue to exist as standalone private repositories in separate networks.

But I agree this is confusing.

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

#183

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: any…

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.

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

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

#185
post #7

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.

It really sounds like the forking and access should be "license aware" which sounds like an absolute nightmare to manage but that would help in this specific scenario?

I can see it simply creating more worms than helpful.

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

#186
post #175

Earlier quoted context omitted.

I'm willing to go out of my way to use a different word if it makes people feel better (the root of the master -> main transition). But this is the rare case where it benefits me by having to type two less characters whenever I refer to the branch! main is truly a win/win.

> I'm willing to go out of my way to use a different word if it makes people feel better Which is just the thing, really. It makes no one feel better. It makes the privileged speaker feel better, with a false sense of virtue. It's a "look at how great I am" signal, nothing more. No one is harmed or made to feel bad by using the word master. Sometimes the adults have to be present in the room, it seems. Saving 2 chara…

It's because main is a goldilocks word for something like a default branch name. It isn't too long and isn't too short. It also isn't shorter in terms of syllables.

Good design :)

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

#187

Earlier quoted context omitted.

Microsoft does this a lot, where they assume that rules that apply to their own organisations apply to all organisations in precisely the same way. If a Microsoft IC leaves, they should lose access to all Git repos, including forks. If Joe Random open-source contributor is removed from an open source repo's access list, their fork shouldn't be wiped. But Microsoft has One Rule To Rule Them All, so they won't make exc…

> There are many aspects of the AAD design that make zero sense until you pause for a second and realise that it is not designed for you. It's designed for Microsoft 365! Business Basic accounts being limited to 7 days of login logs is a huge middle finger to the entire small business sector. Of course they think everyone should just buy Enterprise subscriptions. It's nothing more than a corporate version of "don't b…

Segmenting an enterprise version of a product is generally about finding features that are disproportionately valuable to enterprise (centralized control, policy enforcement, auditing, etc) separating them into a different offering. This lets you charge less to small businesses without having your small business product cannibalize your enterprise business.

This seems basically fine to me? If there are a lot of small businesses who are unsatisfied with Business Basic and can't afford Enterprise then there's an opening for a competitor.

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

#188

Earlier quoted context omitted.

Don't use the "Fork" button in the GitHub UI, then. It is intended for collaboration and establishes and maintains the parent-child relationship of "your fork" and if the parent repo is deleted, so are all forks. If the parent repo is private and goes public, so do all forks. If the parent repo is public and switches to private, so do all forks. This behavior is laid out in docs.github.com and is not secret. This has…

That would make sense if they didn't use the word "fork" for it, that words has a specific meaning when talking about repositiories[0] and it doesn't include a automatically propagating deletions or settings of the original repo, it doesn't actually include ANY automatic propagation, therefore GitHub should use a different word for this kind of fork, something like "Crate child fork" or "Linked fork" or maybe a new w…

GitHub coined this particular use of "fork", and it's always been about having an automatically managed relationship between the original repository and the new one. A copy without that automated connection is a clone.

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

#189
post #81

Earlier quoted context omitted.

It will only be deleted if the repo you fork from is a private repository. The documentation [1] covers the other scenarios, in all of which you keep your copy of the code (including when the public repository is made private later). [1] https://docs.github.com/en/pull-requests/collaborating-with-...

What if the original is made private and then deleted? Does your fork remain?

Yes, the docs linked above say:

"If a public repository is made private and then deleted, its public forks will continue to exist in a separate network."

https://docs.github.com/en/pull-requests/collaborating-with-...

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

#190
post #107

Earlier quoted context omitted.

This doesn’t make any sense to me. My private forks are * mine* and I most certainly do not want GitHub guessing at whether and when to permanently delete them without my consent. Companies of course have the right to manage access to their proprietary source code, for example by only giving access to corporate accounts under their control and reclaiming those accounts when an employee leaves.

> Companies of course have the right to manage access to their proprietary source code, for example by only giving access to corporate accounts under their control and reclaiming those accounts when an employee leaves. This is how it should be done, but is too much overhead for many "IT as a cost centre" companies.

Also, it would ruin my GitHub contributions graph
Post reply on HN