3 ms·

Yes. IMHO the next VCS model should follow a centralized-first, decentralized optional model. Which would be a flip of the decentralized-first model of git. I

Yes. IMHO the next VCS model should follow a centralized-first, decentralized optional model. Which would be a flip of the decentralized-first model of git. I also think GitHub is in a unique space to really innovate on git and it’s a shame they’re not. For example, I shouldn’t need to make a fork to make a PR. That’s absurd and the GitHub server should be able to apply ACLs based on the push identity. There’s a couple more of these suggestions I can think of, but yeah, GitHub should do more in this space.

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 ago
  Oh 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 ago
  If 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.

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 ago
Oh 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 ago
If 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.