4 ms·

Given that Gitlab provides a superset of Github's features, it's possible to operate on both platforms, while clearly indicating where the primary location is.

by cm3 10y ago

Given that Gitlab provides a superset of Github's features, it's possible to operate on both platforms, while clearly indicating where the primary location is. Gitlab has built-in CI, so that can be used exclusively there, and it will be one incentive for users to come to a project's Gitlab instance instead. Personally, I like hosting a repository on Github plus Gitlab for availability reasons, but if Github would finally allow disabling pull requests as well, one could easily make Github a read-only mirror. In light of non-existence of project patch, ticket, release, wiki interoperability protocols, we will either adopt more of FossilSCM's features into git addons (like git-appraise) or someone will write adapters. The most concerning aspect of all of this is that projects that have access to hosted FOSS servers which are fast and under (semi-)direct control give in to peer pressure and move to a closed platform like Github. If, say, Freedesktop.org would run a Gitlab instance, it would prevent the move to Github. I cannot be the first one to think of that.

cm3 10y ago
It would be nice if git would know of multiple remotes in such a way that one could ask it to pull from a random one or fall back to one of the others if the selected is unreachable. Like DNS records for a host. This would be an improvement of the distributed and highly available characteristics of a DVCS.
- heartsucker 10y ago
  for remote in $(git remote); do git pull $remote master && break done
sitkack 10y ago
One alternative is to also push to gitlab/bitbucket/private with some layered snapshots for backups. I still remember all the "free press" github when they nuked all the repos.
- cm3 10y ago
  > One alternative is to also push to gitlab/bitbucket/private with some layered snapshots for backups. Can you explain what you mean by "layered snapshots for backups"? The convention is to push to several remotes because that's part of git's dna, so what's the improvement you're suggesting? > I still remember all the "free press" github when they nuked all the repos. What "free press" incident are you referring to?
  - sitkack 10y ago
    > layered snapshots Git isn't immutable, it is possible to destroy a remote repo. So if one really wants verifiable backups, one needs to take an immutable snapshot of some sort. > free press Like the pentium bug, corporate IT departments everywhere suddenly realized that they used github due to the site wide reset. It was a minor kerfuffle on the net that week.
sytse 10y ago
Thanks for using GitLab! While we can't disable pull requests on GitHub maybe we should add a feature to GitLab to keep importing these pull requests. For this we would need to create forks on GitLab or allow pull/merge requests from code on another server. Opinions are welcome.
- cm3 10y ago
  Yes, automatic connectors would solve a lot. Some users might insist on a bidirectional solution, though it's not necessarily a requirement. In fact, I personally wouldn't want Gitlab to request permission to modify the github copy. At most, I would be okay with it subscribing to feeds and email-replying (no need to oauth) like any github user can. Speaking of disabling, if gitlab allowed disabling pull requests, wiki, issues, etc. and act like a pure git repo, it would solve a problem github refuses to address, namely a project's users wanting to use github/gitlab but the maintainer hosting the primary repo somewhere else. It would also play well with the D in DVCS, which github sort of breaks by leading users to centralize for convenience. I mean, one day github is down, another day gitlab, and so on, it's just how our networks operate.
  - sytse 10y ago
    Cool, I made an issue for the automatic import https://gitlab.com/gitlab-org/gitlab-ce/issues/21147 https://gitlab.com/gitlab-org/gitlab-ce/issues/21147 In GitLab you can already disable merge requests, wiki, and issues per project. See "Edit project".
benologist 10y ago
We should just reject github and watch how fast they roll out a self-hosted version almost nobody wants to host themselves. Today's open source alternatives will be followed by endless more experiments in building a better github, hard to imagine someone "never" nailing it let alone "never" being handed it on a platter because the first website in history annoyed too many of their users at once at just the right time. Going open source wouldn't have saved digg after everyone decided to break their old routine. They had nearly identical open source competitors with variations of their own interface all along, even direct clones. None of their customers ever needed it or benefited from it being a proprietary service either. It's probably a lot more important to Gitlab than Github.
- cm3 10y ago
  It's not primarily about the platform being open source, but relying on a SPOF. It's dangerous and empowers Github to pull all kinds of stuff while they have the marketshare. Today's github may not do shady things, but tomorrows can. It's irresponsible of us to put all our eggs in one basket. At the very least, helping them to be the place where 99% of projects are hosted will allow github to ignore complaints. In fact, it's a good thing Gitlab is not a pure open source project, because there's leadership involved and business interests with real life problems to address. So, the chances of "endless experiments" is low. Sure, if Gitlab was fully open while keeping project leadership and all, it would be even better.
  - benologist 10y ago
    The only reason it's a SPOF is they don't allow anyone to read/run/modify their code... that's what open source covers. I think the problem is we conflate selling the only access to our code with selling access to it. If you need online hosting for your project the alternatives are almost immutable - somebody's server running project management software. No matter what Github does developers are trending towards using open source tools to the extent Microsoft's porting their company to Linux right in front of our faces...
    - benologist 10y ago

by cm3 10y ago

cm3 10y ago

It would be nice if git would know of multiple remotes in such a way that one could ask it to pull from a random one or fall back to one of the others if the selected is unreachable. Like DNS records for a host. This would be an improvement of the distributed and highly available characteristics of a DVCS.

heartsucker 10y ago
for remote in $(git remote); do git pull $remote master && break done

sitkack 10y ago

One alternative is to also push to gitlab/bitbucket/private with some layered snapshots for backups. I still remember all the "free press" github when they nuked all the repos.

cm3 10y ago
> One alternative is to also push to gitlab/bitbucket/private with some layered snapshots for backups. Can you explain what you mean by "layered snapshots for backups"? The convention is to push to several remotes because that's part of git's dna, so what's the improvement you're suggesting? > I still remember all the "free press" github when they nuked all the repos. What "free press" incident are you referring to?
- sitkack 10y ago
  > layered snapshots Git isn't immutable, it is possible to destroy a remote repo. So if one really wants verifiable backups, one needs to take an immutable snapshot of some sort. > free press Like the pentium bug, corporate IT departments everywhere suddenly realized that they used github due to the site wide reset. It was a minor kerfuffle on the net that week.

sytse 10y ago

Thanks for using GitLab! While we can't disable pull requests on GitHub maybe we should add a feature to GitLab to keep importing these pull requests. For this we would need to create forks on GitLab or allow pull/merge requests from code on another server. Opinions are welcome.

cm3 10y ago
Yes, automatic connectors would solve a lot. Some users might insist on a bidirectional solution, though it's not necessarily a requirement. In fact, I personally wouldn't want Gitlab to request permission to modify the github copy. At most, I would be okay with it subscribing to feeds and email-replying (no need to oauth) like any github user can. Speaking of disabling, if gitlab allowed disabling pull requests, wiki, issues, etc. and act like a pure git repo, it would solve a problem github refuses to address, namely a project's users wanting to use github/gitlab but the maintainer hosting the primary repo somewhere else. It would also play well with the D in DVCS, which github sort of breaks by leading users to centralize for convenience. I mean, one day github is down, another day gitlab, and so on, it's just how our networks operate.
- sytse 10y ago
  Cool, I made an issue for the automatic import https://gitlab.com/gitlab-org/gitlab-ce/issues/21147 https://gitlab.com/gitlab-org/gitlab-ce/issues/21147 In GitLab you can already disable merge requests, wiki, and issues per project. See "Edit project".

benologist 10y ago

We should just reject github and watch how fast they roll out a self-hosted version almost nobody wants to host themselves. Today's open source alternatives will be followed by endless more experiments in building a better github, hard to imagine someone "never" nailing it let alone "never" being handed it on a platter because the first website in history annoyed too many of their users at once at just the right time. Going open source wouldn't have saved digg after everyone decided to break their old routine. They had nearly identical open source competitors with variations of their own interface all along, even direct clones. None of their customers ever needed it or benefited from it being a proprietary service either. It's probably a lot more important to Gitlab than Github.

cm3 10y ago
It's not primarily about the platform being open source, but relying on a SPOF. It's dangerous and empowers Github to pull all kinds of stuff while they have the marketshare. Today's github may not do shady things, but tomorrows can. It's irresponsible of us to put all our eggs in one basket. At the very least, helping them to be the place where 99% of projects are hosted will allow github to ignore complaints. In fact, it's a good thing Gitlab is not a pure open source project, because there's leadership involved and business interests with real life problems to address. So, the chances of "endless experiments" is low. Sure, if Gitlab was fully open while keeping project leadership and all, it would be even better.
- benologist 10y ago
  The only reason it's a SPOF is they don't allow anyone to read/run/modify their code... that's what open source covers. I think the problem is we conflate selling the only access to our code with selling access to it. If you need online hosting for your project the alternatives are almost immutable - somebody's server running project management software. No matter what Github does developers are trending towards using open source tools to the extent Microsoft's porting their company to Linux right in front of our faces...
  - benologist 10y ago