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.
Tell HN: GitHub will delete your private repo if you lose access to the original
91–100 of 294 posts
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#92Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#93Earlier quoted context omitted.
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.
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…
> 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]
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#94I 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 standar…
Wonder if any data hoarders have made scripts to clone every site you have started on GitHub?
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#95GitHub 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.
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#96Totally 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.
Is this behavior new? It has been like that for as long as I can remember, certainly before Microsoft bought GitHub.
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#97Earlier 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-…
You can even take it a step further and have a push to origin update your backup as well. https://stackoverflow.com/a/14290145
> In recent versions of Git you can add multiple pushurls for a given remote
Woah, that's really cool, didn't know about that. This is really useful! Thanks for sharing that.
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#98I 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.
Github knows the license of projects. It knows if you forked an open source project.
It knows the license applied to the repository. For a private repo it may not be "released" under that license but planned for release.
If AcmeCorp is planning to release - but hasn't - a project under MIT or whatever, they may have the license declared in the repo but that's not a guarantee it's ever going to be released.
If it's a private repo, and your access has been under your status as an employee, then I don't know that counts as distributed to you under that license. If AcmeCorp later decides to change licenses or not release the software as open source, then it makes sense for GitHub not to let someone continue access.
There are a LOT of holes in the system, but I'm not sure GitHub is in the wrong for deleting access to a private repo if you lose access to an organization or whatever.
Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#99Earlier quoted context omitted.
Even better with cd /media/run/usb-drive/my-backup-repo && git init --bare Bare repositories don't have a working directory. You can still git clone / git pull from them to get the contents. You can also git push to them without clobbering any "local changes" (there aren't any). More detail here: https://www.atlassian.com/git/tutorials/setting-up-a-reposit...
Yeah, better in terms of saving space, but I think it confuses some people, hence I didn't use it in my above example. Previous time I recommended a co-worker to use the `push to a directory` way of copying a git repository, I made them create a bare repository, and they ended up going into the directory to verify it worked and not seeing what they expected. Cue me having to explain the difference between a normal re…
I hear all that, but --bare is necessary in this case because git (by default) won't let you push to a non-bare filesystem branch:
~/temp/a:master $ git push backup
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 212 bytes | 212.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
...
To ../b
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '../b'Re: Tell HN: GitHub will delete your private repo if you lose access to the original
#100This is documented at: https://docs.github.com/en/pull-requests/collaborating-with-...
That's why I usually don't use the official "fork" feature, but clone and push the repository manually instead. I would like to keep the fork network connection on Github, but I don't want to see my fork deleted because of an error, malice or simply lack of knowledge.
Same. Another reason is I don't like how Github inserts "Forked from ..." in the project name. If your "fork" becomes extremely divergent after a couple years (maybe you had a different vision for the project), you are still stuck with the "Fork from..." sub-header, which basically tells users that they should look at the original. I'm otherwise fine putting attribution in a README.