|
|
|
|
|
|
by vtbassmatt
926 days ago
|
|
|
I think there are some serious ergonomic issues with forks as they’re presently implemented. However, I’m curious what you intend from: > the GitHub server should be able to apply ACLs based on the push identity That’s essentially exactly what a GitHub fork _is_ – an ACL’d set of refs you’re allowed to control, separate from upstream’s set of refs. I guess – what would you have us do differently? Disclosure, I work for GitHub and am the product manager for Git stuff. |
|
|
What really slows me down, and honestly just kinda annoys me is that when I’ve cloned some upstream repository onto my machine and made a bug fix, why do I need to then fork the repository once more and push the commit to my fork first and then go through the theatrics of making a PR?
GitHub the server could, for example, fake my branch on the origin/upstream. It doesn’t need to actually make the branch on the upstream, and can smartly make a volatile fork, and prepare the changes to become a PR.
Basically, since the server knows my identity, and knows if I can or can’t make a branch on the upstream repo, it can handle the boilerplate of making a fork for me.
What I want to see from GitHub is embracing the power of there being an authoritative server between the developer and the repository.