4 ms·

GitLab CEO here, thanks for mentioning us as the open source alternative. We think in the short term multiple organizations hosting their own GitLab is the way

by sytse 11y ago

GitLab CEO here, thanks for mentioning us as the open source alternative. We think in the short term multiple organizations hosting their own GitLab is the way to go. It is hard to do issues and pull/merge requests in a decentralized way (the OP is impressive but it shows distributed git instead of distributed GitHub). I would like to see federated merge requests http://feedback.gitlab.com/forums/176466-general/suggestions/5097708-implement-cross-server-federated-merge-requests http://feedback.gitlab.com/forums/176466-general/suggestions...

JoshTriplett 11y ago
Not just federated merge requests, but federated one-click cloning. Given a "home" GitLab instance, you should be able to click a button on any GitLab repository (or on repositories elsewhere, based on some spec), and end up with a clone of that repository in your "home" instance. That should be possible via browser support for site-based URL handlers; for browsers without such support, you could also have a URL on the main GitLab site that people can register with to redirect to their "home" instance.
- sytse 11y ago
  Interesting idea. I think it is harder to do this than the federated merge requests because of the permissions, but I love the idea.
  - JoshTriplett 11y ago
    You'd be logged into your "home" instance, which gives you the permissions you need. You click a link on the remote site, which takes you (either directly via URL handler or indirectly via central site redirect) to your home instance with appropriate values filled in, and prompts you to confirm (to avoid CSRF).
    - sytse 11y ago
      OK, that seems pretty straightforward.
    - kragen 11y ago
      That sounds like federated two-click cloning, not federated one-click cloning. Maybe you could batch up the confirmations and get federated 1.1-click cloning?
- walterbell 11y ago
  By "site-based URL handler", do you mean https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers https://developer.mozilla.org/en-US/docs/Web-based_protocol_...?
  - JoshTriplett 11y ago
    Yes, exactly. Use URLs like gitfork:https://.. https://... and register a handler for the "gitfork" scheme. (The site could also register a handler for git:// , but that won't help for http or https, and git:// isn't secure, so I'd suggest avoiding that.) As a backup, also provide links to some central domain that allows people to configure where they'd like to redirect it to.
js2 11y ago
It is hard to do issues and pull/merge requests in a decentralized way ...Over the web... I mean, Git and Linux are developed via email lists, which is a decentralized way of sending pull/merge requests, isn't it? I guess you could argue the mailing list is hosted on a server, fine. So then fine, usenet. Yeah, email and nntp are old crufty technologies and there are obviously advantages to having a web based interface and a central place to go for a project. But git itself certainly supports a decentralized mechanism for merging. So then the question really is, how do you decentralize a web interface, isn't it? The dvcs itself isn't the problem.
- sytse 11y ago
  Yeah, decentralizing the web interface is hard. Maybe it is the wrong question. Maybe it is, how can you use usenet to get an overview of issues and do code reviews.
- doragcoder 11y ago
  Wouldn't a decentralized web interface be webmail (i.e. Gmail)? Then along the Gmail theme, a plug in could make things look much like a static website. Where "conversation view" becomes a "repository view".
  - nicky0 11y ago
    There's nothing decentralised about Gmail.
- zAy0LfpBZLC8mAC 11y ago
  Why would you want to have a web interface? The web stack is crufty as hell, and the web has the one major problem that it forces everyone to use the same UI for accessing a service. With email, for example, clueless users can get by with some simple webmail interface, but that does not prevent me from managing my mails efficiently with mutt. The standardization of UIs instead of protocls and data formats is one of the worst regressions in IT in recent years, IMO.

by sytse 11y ago

JoshTriplett 11y ago

Not just federated merge requests, but federated one-click cloning. Given a "home" GitLab instance, you should be able to click a button on any GitLab repository (or on repositories elsewhere, based on some spec), and end up with a clone of that repository in your "home" instance. That should be possible via browser support for site-based URL handlers; for browsers without such support, you could also have a URL on the main GitLab site that people can register with to redirect to their "home" instance.

sytse 11y ago
Interesting idea. I think it is harder to do this than the federated merge requests because of the permissions, but I love the idea.
- JoshTriplett 11y ago
  You'd be logged into your "home" instance, which gives you the permissions you need. You click a link on the remote site, which takes you (either directly via URL handler or indirectly via central site redirect) to your home instance with appropriate values filled in, and prompts you to confirm (to avoid CSRF).
  - sytse 11y ago
    OK, that seems pretty straightforward.
  - kragen 11y ago
    That sounds like federated two-click cloning, not federated one-click cloning. Maybe you could batch up the confirmations and get federated 1.1-click cloning?
walterbell 11y ago
By "site-based URL handler", do you mean https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers https://developer.mozilla.org/en-US/docs/Web-based_protocol_...?
- JoshTriplett 11y ago
  Yes, exactly. Use URLs like gitfork:https://.. https://... and register a handler for the "gitfork" scheme. (The site could also register a handler for git:// , but that won't help for http or https, and git:// isn't secure, so I'd suggest avoiding that.) As a backup, also provide links to some central domain that allows people to configure where they'd like to redirect it to.

js2 11y ago

It is hard to do issues and pull/merge requests in a decentralized way ...Over the web... I mean, Git and Linux are developed via email lists, which is a decentralized way of sending pull/merge requests, isn't it? I guess you could argue the mailing list is hosted on a server, fine. So then fine, usenet. Yeah, email and nntp are old crufty technologies and there are obviously advantages to having a web based interface and a central place to go for a project. But git itself certainly supports a decentralized mechanism for merging. So then the question really is, how do you decentralize a web interface, isn't it? The dvcs itself isn't the problem.

sytse 11y ago
Yeah, decentralizing the web interface is hard. Maybe it is the wrong question. Maybe it is, how can you use usenet to get an overview of issues and do code reviews.
doragcoder 11y ago
Wouldn't a decentralized web interface be webmail (i.e. Gmail)? Then along the Gmail theme, a plug in could make things look much like a static website. Where "conversation view" becomes a "repository view".
- nicky0 11y ago
  There's nothing decentralised about Gmail.
zAy0LfpBZLC8mAC 11y ago
Why would you want to have a web interface? The web stack is crufty as hell, and the web has the one major problem that it forces everyone to use the same UI for accessing a service. With email, for example, clueless users can get by with some simple webmail interface, but that does not prevent me from managing my mails efficiently with mutt. The standardization of UIs instead of protocls and data formats is one of the worst regressions in IT in recent years, IMO.