261–270 of 294 posts
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.
Does that limit submitting PRs to the original repo somehow?
Earlier quoted context omitted.
> 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
Earlier quoted context omitted.
> 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 priv…
Earlier quoted context omitted.
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.
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-...
Earlier quoted context omitted.
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.
Right, the entire point of GitHub forks is to make it easier to upstream your local changes to the original repository. If you have no interest in doing that you shouldn't use a fork.
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 standar…
> 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-…
Earlier quoted context omitted.
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.
a cron job ought to do this. Try something like Cloud Scheduler that can automate this for you.( I am not sure what the equivalent is in AWS)
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…
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.
Earlier quoted context omitted.
to my private repository, but not their own private repository. like it happens when a public repo goes private: I don't loose access to my fork of the repo but access to the original repo
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…
"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 people to do that."
If somebody sends me a word document per Email, I can edit it without someone else being able to delete the modified word document.