4 ms·
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 sho
by vtbassmatt 3y 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.
- aaomidi 3y agoOh awesome, thank you for asking for clarification! 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.
- deleted 3y ago[deleted]
- mappu 3y agoIf it's the same underlying repo then it would be nice to avoid needing two git remotes for it (original + fork). But how you do that, i'm not sure.