Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

281–290 of 294 posts

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

#281

Post by MereInterest »

mattigames wrote: post #277
MereInterest wrote: post #276

Earlier quoted context omitted.

I'm not sure exactly the distinction that you're trying to make. I see GitHub's use of "fork" as a specific application of the broader meaning of "fork", not an invention of a new and distinct concept. Just as putting "wheels" onto a steam engine can produce a new type of vehicle but doesn't change the concept of "wheels", GitHub's use of "fork" doesn't fundamentally change the broader concept of "fork".

If any changes done to the parent repository propagate automatically to "forked" repositories without the explicit consent of the _owner_ of the fork then it does change the broader concept of fork, and to follow your analogy it would be like calling a caterpillar track a wheel. If this is acceptable because the original version it's a private repository that is unrelated, what we are discussing is the meaning of the…

I think we are in agreement. Because access to the "forked" repository was removed without the consent of the owner of the fork, it is inaccurate for GitHub to describe it as a "fork". For clarity, I would also describe the "owner" of the fork as the person who created the fork.

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

#282

Post by masukomi »

account42 wrote: post #263
ssalka wrote: post #190

Earlier quoted context omitted.

Also, it would ruin my GitHub contributions graph

A simple script and a cron job will fix that problem.

no need for a cron job

custom fake git history with this: https://github.com/artiebits/fake-git-history

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

#283

Post by mckn1ght »

jmondi wrote: post #183
kitkat_new wrote: post #145

Earlier quoted context omitted.

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

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!

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

#284

Post by remram »

saltcured wrote: post #278
remram wrote: post #268

Earlier quoted context omitted.

My question is not how to run it, but what to run. If your scheduled task does a full clone every time to upload as ZIP to S3, it is massively inefficient. Even if you use something like Restic, because the Git pack file will have nothing in common with the previous one.

Clone each repo locally. Periodically do "git fetch -p" for each repo to update the local copy of upstream content. Run some periodic task like restic or rclone (depending on whether you want point in time snapshots or just a mirror of latest state) to mirror these local repos into your S3 bucket. The local clones should evolve incrementally due to "git fetch", and then the restic or rclone task should figure out how…

But that's... exactly what I described and asked how to avoid...

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

#285

Post by yencabulator »

remram wrote: post #210
sangnoir wrote: post #136

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 wonder if there is an efficient way to do direct incremental git-to-S3 backups, or if you have to do this, run a Git mirror and do regular filesystem-level backups of it.

https://git-scm.com/docs/git-bundle creates a single file that contains everything in A not in B, so e.g. the delta between the state of the repository yesterday and the state today (for all the refs in it). You just need to produce the "rev list" to save.

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

#287

Post by b1nj0y »

voytec wrote: post #240
tux3 wrote: 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.

OP states that it was "an MIT-licensed open source project". It appears that Microsoft has lack of licensing understanding not only when it comes to copilot. If they are punishing users just under an assumption that user is doing what they are doing (using someone's codebase with non-permissive licence, possibly unlawfully), it's just silly.

agree

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

#288

Post by Ferret7446 »

TheRealPomax wrote: post #64
andyjohnson0 wrote: post #40

Earlier quoted context omitted.

> It will only be deleted if the repo you fork from is a private repository This makes sense. Thank you for clarifying that important detail. It seems to be missing from the parts of the discussion I've read here.

No, it doesn't. It only makes sense until you stop and go "Wait, no, hold on a minute. Why would they delete the fork instead of simply severing the fork relation in their fork relations table?".

Consider:

You have access to many private company files. After you leave the company, the company is obligated to send you copies of all of the files because you may have linked to them. After all, you could have made personal copies of all of the files, so you should still retain access through links.

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

#289

Post by IncRnd »

kitkat_new wrote: post #270
IncRnd wrote: post #236

Earlier quoted context omitted.

You are trying to construct a scenario, where you have the ability to elevate your own rights to somebody else's repo's contents. Name a computer system that intentionally allows people to do that. That similar to demanding that you can still send emails on a terminated email account from your prior employer. If you want to continue your access to that private repo's source code, you now need to speak to them. They o…

I am not trying to construct anything. I just described what happens and what I expect. "where you have the ability to elevate your own rights to somebody else's repo's contents." This is not an accurate description. There are two repositories: the original repository, and the fork. Nowhere I want to to elevate my rights regarding the fork to the original repository. " Name a computer system that intentionally allows…

You keep trying to claim that a different person's private repo that you have forked has somehow given you ownership over the contained information. That's just not the case. Forking their code doesn't make it yours.

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

#290

Post by saltcured »

remram wrote: post #284
saltcured wrote: post #278

Earlier quoted context omitted.

Clone each repo locally. Periodically do "git fetch -p" for each repo to update the local copy of upstream content. Run some periodic task like restic or rclone (depending on whether you want point in time snapshots or just a mirror of latest state) to mirror these local repos into your S3 bucket. The local clones should evolve incrementally due to "git fetch", and then the restic or rclone task should figure out how…

But that's... exactly what I described and asked how to avoid...

I had trouble parsing your earliest comment, so I only tried to address the incremental backup concern. I may not have understood the conversation, but it seemed like you claimed that a filesystem level backup of a clone was not going to produce incremental backup IO in practice.

A periodic fetch into a persistent cloned repo will be incremental unless the upstream is doing something crazy with frequent branch deletions and repacks. In practice, most upstream repos I encounter behave relatively monotonically. They accumulate new commits and branch/tag heads but do not often create garbage or need repacking.

A periodic backup of the cloned repo will also be incremental if using an appropriate tool like restic or rclone-copy. Also, since the clone only changes during the fetch, you can serialize these in one periodic job and be confident that you are making a consistent snapshot of the repo.

The advantage of this approach is its simplicity. It is easy to reason about and easy to work with the backups to restore a repo without having to learn about other tools. It's the kind of thing I could feel comfortable setting up and running for years on end with little supervision.

A more sophisticated approach that integrates with git hooks, e.g. to do event-driven rather than periodic backup, is plausible but I think could quickly get in the way of itself. And if working with a hosted upstream, you would need to integrate with their proprietary hooks, e.g. GitHub actions, and deal with other restrictions of the hosting environment. Such a solution likely brings new failure modes and may not be a worthwhile tradeoff...

Post reply on HN