4 ms·

Not only is this a great idea but there's no reason this couldn't be an API layer over any number of underlying source control implementations (Git, Mercurial,

by mikece 8y ago

Not only is this a great idea but there's no reason this couldn't be an API layer over any number of underlying source control implementations (Git, Mercurial, Bazaar, TFVC, SVN, etc). Could open up all kinds of possibilities for CI/CD tooling and workflows as well.

Arkanosis 8y ago
This is actually being discussed as well: https://framalistes.org/sympa/arc/git-federation/2018-06/msg00023.html https://framalistes.org/sympa/arc/git-federation/2018-06/msg... The scope of GitPub is still under active definition, and it might end up not being specific to git only. If you're a stakeholder of any service that could federate based on Mercurial, Bazaar… you're more than welcome to give your input to the working group.
- mikece 8y ago
  First thing first: I would hope that "Git" would be removed from the GitPub name. I'm in favor of replacing Git in the process and having both a new client source control implementation and server API set (SourcePub?) that are designed with each other in mind, eases federation, and is both powerful and easier for new devs than Git (Hg managed this... not sure why a Git replacement can't do the same).
  - deleted 8y ago
    [deleted]
  - Arkanosis 8y ago
    GitPub (or whatever it'll be named then) does not intend to replace git or any other VCS. Its stated goal is to enable federation between services such as GitHub, GitLab, Gogs, Gitea, Pagure… which happen to use git. In other words, it means that if GitPub was adopted by these services, you could submit a merge request from Pagure to Gitlab, or star a GitHub project from your own Gitea instance, among many other things.
    - ReverseCold 8y ago
      > star a GitHub project from your own Gitea instance How do federated networks prevent someone from making a few hundred accounts and starring/liking a bunch of posts?
      - r3bl 8y ago
        Does it need to prevent them? Do stars in a repo represent something significant?
      - OJFord 8y ago
        How does a centralised network prevent someone from making a few hundred accounts and starring/liking a bunch of posts? We seem to be doing OK by not caring much.
        Rjevski 8y ago
        Well in this case why Github, GitLab, etc.. do not allow you to "star" a repo more than once? I'm fine with stars not being significant, but it's still not good if a malicious actor can suddenly spoof hundreds of accounts and spam stars, comments and what-not.
        OJFord 8y ago
        Because that's a completely different interaction. You can still create another account and star it again. Sure, your IP will be rate-limited (GH at least) if you script it and start hammering stars, but that's not because it wants to protect the integrity of the repo star count.
- sytse 8y ago
  Great to see this initiative, at GitLab we're actively following this, thanks for keeping us posted https://gitlab.com/gitlab-org/gitlab-ce/issues/4013#note_79942659 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013#note_799...
  - cjslep 8y ago
    Glad to hear! I hope GitLab will also provide feedback to the community group.
    - sytse 8y ago
      For sure, is there already a proposal for federated merge requests? Or can you make those from the activity stream? That would by the minimal viable change as far as I can see.
      - Arkanosis 8y ago
        Federated merge requests are being discussed in this thread: https://framalistes.org/sympa/arc/git-federation/2018-06/msg00122.html https://framalistes.org/sympa/arc/git-federation/2018-06/msg... It's way too early for a proposal, but if someone from GitLab wants to give some input, that's more than welcome. Thanks!
        sytse 8y ago
        Thanks for the pointer!
  - deleted 8y ago
    [deleted]
politician 8y ago
I really hope they stick with Git and produce something concrete rather than trying to shoehorn a diverse collection of version control models into the same API. The last thing you want is the sort of lowest common denominator solution that everyone agrees on but is otherwise useless. Later, after the GitPub federation approach is proven, let another team take up the torch for AnyPub.
- doubleunplussed 8y ago
  To me it seems like the real power of and differences between tools is apparent mostly in the context of offline history editing. Once you're making pull requests, nobody wants anything complex in the PR. Lowest common denominator - "here is a set of commits" might be fine.

by mikece 8y ago

Arkanosis 8y ago

This is actually being discussed as well: https://framalistes.org/sympa/arc/git-federation/2018-06/msg00023.html https://framalistes.org/sympa/arc/git-federation/2018-06/msg... The scope of GitPub is still under active definition, and it might end up not being specific to git only. If you're a stakeholder of any service that could federate based on Mercurial, Bazaar… you're more than welcome to give your input to the working group.

mikece 8y ago
First thing first: I would hope that "Git" would be removed from the GitPub name. I'm in favor of replacing Git in the process and having both a new client source control implementation and server API set (SourcePub?) that are designed with each other in mind, eases federation, and is both powerful and easier for new devs than Git (Hg managed this... not sure why a Git replacement can't do the same).
- deleted 8y ago
  [deleted]
- Arkanosis 8y ago
  GitPub (or whatever it'll be named then) does not intend to replace git or any other VCS. Its stated goal is to enable federation between services such as GitHub, GitLab, Gogs, Gitea, Pagure… which happen to use git. In other words, it means that if GitPub was adopted by these services, you could submit a merge request from Pagure to Gitlab, or star a GitHub project from your own Gitea instance, among many other things.
  - ReverseCold 8y ago
    > star a GitHub project from your own Gitea instance How do federated networks prevent someone from making a few hundred accounts and starring/liking a bunch of posts?
    - r3bl 8y ago
      Does it need to prevent them? Do stars in a repo represent something significant?
    - OJFord 8y ago
      How does a centralised network prevent someone from making a few hundred accounts and starring/liking a bunch of posts? We seem to be doing OK by not caring much.
      - Rjevski 8y ago
        Well in this case why Github, GitLab, etc.. do not allow you to "star" a repo more than once? I'm fine with stars not being significant, but it's still not good if a malicious actor can suddenly spoof hundreds of accounts and spam stars, comments and what-not.
        OJFord 8y ago
        Because that's a completely different interaction. You can still create another account and star it again. Sure, your IP will be rate-limited (GH at least) if you script it and start hammering stars, but that's not because it wants to protect the integrity of the repo star count.
sytse 8y ago
Great to see this initiative, at GitLab we're actively following this, thanks for keeping us posted https://gitlab.com/gitlab-org/gitlab-ce/issues/4013#note_79942659 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013#note_799...
- cjslep 8y ago
  Glad to hear! I hope GitLab will also provide feedback to the community group.
  - sytse 8y ago
    For sure, is there already a proposal for federated merge requests? Or can you make those from the activity stream? That would by the minimal viable change as far as I can see.
    - Arkanosis 8y ago
      Federated merge requests are being discussed in this thread: https://framalistes.org/sympa/arc/git-federation/2018-06/msg00122.html https://framalistes.org/sympa/arc/git-federation/2018-06/msg... It's way too early for a proposal, but if someone from GitLab wants to give some input, that's more than welcome. Thanks!
      - sytse 8y ago
        Thanks for the pointer!
- deleted 8y ago
  [deleted]

politician 8y ago

I really hope they stick with Git and produce something concrete rather than trying to shoehorn a diverse collection of version control models into the same API. The last thing you want is the sort of lowest common denominator solution that everyone agrees on but is otherwise useless. Later, after the GitPub federation approach is proven, let another team take up the torch for AnyPub.

doubleunplussed 8y ago
To me it seems like the real power of and differences between tools is apparent mostly in the context of offline history editing. Once you're making pull requests, nobody wants anything complex in the PR. Lowest common denominator - "here is a set of commits" might be fine.