6 ms·

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

by evouga 4y ago

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.

naikrovek 4y ago
> 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-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-...
- jefftk 4y ago
  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.
  - kadoban 4y ago
    The right way is to make it public first? That's insanity. Making a repo public just to delete it would be a huge information leak even if it was short in duration.
    - Ennea 4y ago
      Just force push something very empty to it before making it public. One more step, yay..
  - account42 4y ago
    So they did think about this use case (deleting a private repo without deleting forks) but did not bother implementing a proper choice for the repo delete flow?
- hoherd 4y ago
  This seems really bizarre to me. They seem to want people to have the network of connected GH repositories, but this behavior promotes "forking" a project in a way that breaks that network, which is to `git clone` and then create a new repo from that clone. To put it another way, if the user had "forked" the GH repo onto GitLab, there would be no data loss, but that behavior would promote using GH in a way that breaks the upstream/downstream relationship that you see on GH. It's even worse that the deleted fork was private. What impact does GH expect deleting the hosted private repository has on folks who really want to keep a private copy of the repo, such as offline or on another git hosting site? I'm really struggling to see any real-world positive sides to this mechanism. Seems like an ineffectual legal or compliance CYA.
mike_d 4y ago
> My private forks are mine Your employment agreement disagrees. Blame the confusion on the blurry line GitHub draws between forking work repos into personal accounts.
- pxc 4y ago
  Did you forget the part where this code is MIT-licensed? Yes, they don't own it, but the code is still 'theirs' to keep forever as they see fit.
  - shagie 4y ago
    The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is. The person may be able to find the original code that was MIT licensed but that doesn't mean that the work done in house is also MIT licensed and that they have any right to it.
    - pxc 4y ago
      OP wrote > That was an MIT-licensed open source project I worked on years ago. which to me implies that OP also received the code under the MIT license and not some other license.
      - shagie 4y ago
        However, the work done while at the employer may not have been done under the MIT license unless permission to license it and distribute it under the MIT license was given by legal.
    - eyelidlessness 4y ago
      IANAL but… > The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source … this is less compelling to me than this: > and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is. AFAIK, changing the licensing terms of an MIT project isn’t retroactive to prior licenses. A quick search seems to confirm that. The possibility of more restrictive or revocable licensing of subcomponents is more compelling as a rebuttal to “mine” at a philosophical level, but it’s not compelling from the perspective of GitHub revoking access. They’re welcome to comply with relevant legal actions, but they’re not actually the police of your licensee status and don’t even attempt to be. Ultimately it’s the person who maintains the private repo who is responsible for and to any license challenges. GitHub isn’t a party or privy to those agreements, and again doesn’t have any pretense of such except compelled by legal action. And I give them the benefit of the doubt that this isn’t their motive. This behavior is part of their own permissions model, and their own model of the relationship between “forks” and “private”, as defined by their own use cases. It’s a surprising one, but it needn’t have anything at all to do with their view of any given user’s repo’s license compliance.
Marsymars 4y ago
> 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.
- ssalka 4y ago
  Also, it would ruin my GitHub contributions graph
  - account42 4y ago
    A simple script and a cron job will fix that problem.
    - masukomi 4y ago
      no need for a cron job custom fake git history with this: https://github.com/artiebits/fake-git-history https://github.com/artiebits/fake-git-history
- therealdrag0 4y ago
  It why would GitHub care to build functionality to behave how companies who aren’t paying them want it to behave?
vetrom 4y ago
Any (quite relevant actually) discussion of SCM policy and management aside, you've got to remember: There is no 'cloud', it's just somebody else's computer.
madduci 4y ago
So the main solution would be not forking, but cloning and straight create a separate project? Will it work?
- snowwrestler 4y ago
  Simply saving a copy of the fork locally would be sufficient to keep a copy of it.
- kevincox 4y ago
  Yes, I believe that if you push a repo to GitHub from a local copy instead of using their web-based "fork" feature it will not deduplicate the repositories. IDK if this affects your ability to submit pull requests though.
comprev 4y ago
My client recently moved from GitLab (self hosted - many teams had their own isolated server) to GitHub.com and managing access for the thousands of developers has been a small headache. We were encouraged to use our personal GitHub accounts instead of making new ones. They are promoting "internal open source", yet due to a wild variety of permissions, colleagues can't fork to their own space or push a branch for a PR. Chasing the repo owners or at least someone with authority to grant permission is rarely worth the hassle.

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

by evouga 4y ago

naikrovek 4y ago

> 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-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-...

jefftk 4y ago
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.
- kadoban 4y ago
  The right way is to make it public first? That's insanity. Making a repo public just to delete it would be a huge information leak even if it was short in duration.
  - Ennea 4y ago
    Just force push something very empty to it before making it public. One more step, yay..
- account42 4y ago
  So they did think about this use case (deleting a private repo without deleting forks) but did not bother implementing a proper choice for the repo delete flow?
hoherd 4y ago
This seems really bizarre to me. They seem to want people to have the network of connected GH repositories, but this behavior promotes "forking" a project in a way that breaks that network, which is to `git clone` and then create a new repo from that clone. To put it another way, if the user had "forked" the GH repo onto GitLab, there would be no data loss, but that behavior would promote using GH in a way that breaks the upstream/downstream relationship that you see on GH. It's even worse that the deleted fork was private. What impact does GH expect deleting the hosted private repository has on folks who really want to keep a private copy of the repo, such as offline or on another git hosting site? I'm really struggling to see any real-world positive sides to this mechanism. Seems like an ineffectual legal or compliance CYA.

mike_d 4y ago

> My private forks are mine Your employment agreement disagrees. Blame the confusion on the blurry line GitHub draws between forking work repos into personal accounts.

pxc 4y ago
Did you forget the part where this code is MIT-licensed? Yes, they don't own it, but the code is still 'theirs' to keep forever as they see fit.
- shagie 4y ago
  The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is. The person may be able to find the original code that was MIT licensed but that doesn't mean that the work done in house is also MIT licensed and that they have any right to it.
  - pxc 4y ago
    OP wrote > That was an MIT-licensed open source project I worked on years ago. which to me implies that OP also received the code under the MIT license and not some other license.
    - shagie 4y ago
      However, the work done while at the employer may not have been done under the MIT license unless permission to license it and distribute it under the MIT license was given by legal.
  - eyelidlessness 4y ago
    IANAL but… > The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source … this is less compelling to me than this: > and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is. AFAIK, changing the licensing terms of an MIT project isn’t retroactive to prior licenses. A quick search seems to confirm that. The possibility of more restrictive or revocable licensing of subcomponents is more compelling as a rebuttal to “mine” at a philosophical level, but it’s not compelling from the perspective of GitHub revoking access. They’re welcome to comply with relevant legal actions, but they’re not actually the police of your licensee status and don’t even attempt to be. Ultimately it’s the person who maintains the private repo who is responsible for and to any license challenges. GitHub isn’t a party or privy to those agreements, and again doesn’t have any pretense of such except compelled by legal action. And I give them the benefit of the doubt that this isn’t their motive. This behavior is part of their own permissions model, and their own model of the relationship between “forks” and “private”, as defined by their own use cases. It’s a surprising one, but it needn’t have anything at all to do with their view of any given user’s repo’s license compliance.

Marsymars 4y ago

> 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.

ssalka 4y ago
Also, it would ruin my GitHub contributions graph
- account42 4y ago
  A simple script and a cron job will fix that problem.
  - masukomi 4y ago
    no need for a cron job custom fake git history with this: https://github.com/artiebits/fake-git-history https://github.com/artiebits/fake-git-history
therealdrag0 4y ago
It why would GitHub care to build functionality to behave how companies who aren’t paying them want it to behave?

vetrom 4y ago

Any (quite relevant actually) discussion of SCM policy and management aside, you've got to remember: There is no 'cloud', it's just somebody else's computer.

madduci 4y ago

So the main solution would be not forking, but cloning and straight create a separate project? Will it work?

snowwrestler 4y ago
Simply saving a copy of the fork locally would be sufficient to keep a copy of it.
kevincox 4y ago
Yes, I believe that if you push a repo to GitHub from a local copy instead of using their web-based "fork" feature it will not deduplicate the repositories. IDK if this affects your ability to submit pull requests though.

comprev 4y ago

My client recently moved from GitLab (self hosted - many teams had their own isolated server) to GitHub.com and managing access for the thousands of developers has been a small headache. We were encouraged to use our personal GitHub accounts instead of making new ones. They are promoting "internal open source", yet due to a wild variety of permissions, colleagues can't fork to their own space or push a branch for a PR. Chasing the repo owners or at least someone with authority to grant permission is rarely worth the hassle.