Hacker News Reader

Comment by JD557 | Hacker News Reader

> Over the years, several developers have asked why we're not on GitHub. The perception is that "everybody" is on GitHub, and some developers don't take your project seriously if it's not on GitHub.

This is the sad truth. It doesn't matter anymore if Bitbucket/Gitlab/etc. are better than GitHub: The social pressure for open source projects to move to GitHub is so high that the alternatives don't even stand a chance.

Maybe a meta-search engine for open source projects could help the competition, but if all projects are on GitHub, who would use such a search engine?

P.S.: I actually like GitHub, I'm just sad that all cool changes that GitLab has made recently will end up being mostly ignored by the OSS community. Even if they fixed their speed problem (which I think is their biggest downside compared to GitHub), no project would move there because "everybody is on GitHub".

View on HN

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.

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.

    for remote in $(git remote); do
        git pull $remote master && break
    done

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.

> 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?

> 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.

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.

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.

Cool, I made an issue for the automatic import 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".

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.

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.

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...

Belated edit I wasn't criticising Gitlab, I meant it's probably more important to Gitlab that Github be proprietary.

They do have a self-hosted version but it's probably not what you have in mind since it's quite expensive and is aimed at enterprises. It's called GitHub Enterprise. It's a black box virtual appliance since actually installing and maintaining all of the various services GitHub runs on independently would be a tough sell for a lot of companies.

The worst thing is that eventually, github will start to want to monetise even more, and we'll see it turn into SourceForge, at which point many projects that have tied themselves into github rather than spreading out more carefully amongst other git hosts will face a bit of an existential crisis.

We'll never learn.

This is part of why I have some issue with the Golang packaging story, it pretty much requires you to refer to dependent packages as `host.com/user/pkg`, so in most cases it's `github.com/...`. You can manually rewrite this, but that's not really ideal.

In case whether 'search & replace' method is not an option you may create your own 'proxy' server like gopkg.in [1], since Golang packages don't have to be only on GitHub [2] you may set up mirroring rules to overcome problems with package location, version/revision, or library when GitHub downtime may occur. Personally, I don't think if creating own proxy server as solution would be quite big deal whether there are many various dependency tools for Go. 'Search & replace' is not mission impossible either. Go is not PHP - it just won't compile if (local) dependency is broken.

[1]: https://github.com/niemeyer/gopkg

[2]: https://golang.org/cmd/go/#hdr-Remote_import_paths

> no project would move there because "everybody is on GitHub".

If they had a solid sync service between GitLab and GitHub; PRs, issues, code, everything then things could get interesting and some people might consider the switch.

Right now you can import your entire project easily in GitLab, from GitHub (incl everything) [0].

You can also sync any remote repository (two-ways) [1] in GitLab EE (which runs on GitLab.com).

I made an issue for a continuous sync in GitLab [2]. Would love to get your feedback.

[0]: http://docs.gitlab.com/ee/workflow/importing/import_projects... your project from GitHub to GitLab

[1]: http://docs.gitlab.com/ee/workflow/repository_mirroring.html

[2]: https://gitlab.com/gitlab-org/gitlab-ee/issues/904

Tell these people to take a walk. Seriously, if their nose is too high, why bother with them anyway?

The geeks and nerds have become the bullies. It's sad.

If Gitlab is listening (like they often do), I think we just figured out a solid plan:

1. Fix the speed problem

2. Build yourself such a meta search engine for OSS projects

And advertise the built-in CI feature in a major way.

We changed our homepage to reflect all the things you can do with GitLab? https://about.gitlab.com/

What other things do you think we should do?

The features are all listed, but just by glancing over the site it's not clear what extra features are provided on gitlab.com for open source projects that would require webhooks to external services on github and the associated security risks. So, in addition to listing features of Gitlab Community and EE it would be helpful to see that for example there is built-in CI support that targets X platforms.

We're always listening.

1. We're working on the speed. It has gotten a lot better with the last few releases. The release of tomorrow is another big step, especially for diffs. We have a number of issues for this, I'm linking one of the meta issue here, but be sure to check the release of tomorrow for graphs and whatnot [0]

2. It's definitely an interesting idea. I made an issue [1]. Love it if you would provide some feedback. I wonder whether we'd be allowed to do such a thing, but it seems to be in the interest of the end-user, which is a good thing.

[0]: https://gitlab.com/gitlab-com/infrastructure/issues/59

[1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/903

If you are serious about doing [1] and are willing to throw the hardware resources behind this initiative, I can probably work with you guys to make GitLab, a central point for searching all open source projects that are versioned by Git. I've probably indexed over 100,000 public repos from GitHub as part of testing, and to be honest, one of the biggest problem has always been finding repos worth indexing.

You can learn more about my search technology at https://gitsense.com/blog

However, it's worth noting that GitSense is not optimized for searching across 1000+ repositories at once and to be honest, this is never a good thing in my opinion. When it comes to code searches, I believe it should be curated, where some domain expert can say if you are working on release x, for open source project y, these are the branches/repos you will probably be interested in and so forth.

Until we have artificial intelligence, like we see in movies, nobody is going to produce relevant code search results, by searching tens of thousands of repos. Software development is completely context driven and what mattered for one release, can become completely irrelevant in the next.

What GitSense is optimized for, is searching across logical groupings of code at the branch level. This can be 1000 branches from 1000 repos or 1000 branches from the same repo/forks.

If GitLab is serious about being a central point for all open source code searches and are okay with providing logical searches at the branch level, let me know. You can contact me via my email in my HN profile. And it's probably worth noting, since the GitSense indexing engine/search engine are completely separate from the frontend, it'll be easy enough for GitLab add their own interface.

Google Code Search was awesome, and it searched from all indexed projects at once. As does https://codesearch.debian.net/

The problem with Google Code Search and the one that you mentioned is, you can never be certain the match is relevant/correct. And the reason for this is, you are always searching against a single branch/timeline.

Definitions can change from one release to another. Function behavior can change from one release to another and so forth.

Searching across millions of repos is not difficult, if you are willing to accept the matches returned may or may not be relevant. What is extremely difficult, is building a search solution that can take into consideration all the changes, on every branch, from the millions of repos. And this is the problem nobody is going to solve anytime soon.

Instead of meta-search, git needs meta repositories. I should be able to specify an alias which represents multiple repositories, not just URLs like it does now. This way I could upload to e.g. @myrepo and have it upload across github, gitlab, and other git based hosts. Sure it could be done pretty easily with shell scripts, but it would help the cause if it were built in to git. I'm a git novice so it may already have this feature, but if not it seems like it would help with this problem.

Reply on news.ycombinator.com