Should be an interesting research tool to see how often we use shitty commit messages when trying to get something fixed...

https://github.com/search?utf8=%E2%9C%93&q=fix&type=Commits&...

"Actually fixed" https://github.com/search?utf8=%E2%9C%93&q=%22actually+fixed...

"fixed this time": https://github.com/search?utf8=%E2%9C%93&q=%22fixed+this+tim...

Just the first page is pretty funny.

"really really fixed this time for real"

I'm definitely guilty of this one. My big mistake is I always think "oh this will be an easy fix" when configuring a CI system, and then it doesn't work, and I don't split into a new branch then and there.

These links do not work if you're not logged in.

Yeah I think github does that to prevent bots searching the codebase as easily.

I'm curious how long it took to build their search index, and how they do it/what technologies/algorithms they are using. That's a lot of data!

based on the how Github Enterprise works, they probably use the same technology, meaning ElasticSearch.

I wonder how often they rebuild the indexes, and scan for new commits. That's an interesting problem to solve actually

Google put all GitHub data in BigQuery a while back [1]. What took them so long?

[1] https://cloud.google.com/bigquery/public-data/github

Well this is an apple and orange thing. With BigQuery, they deal with data dumps, while GitHub deals with constant streams of new data. However I do agree with the "What took so long?" sediment.

This is something that should have been in place 3 years ago. I guess it's a good that GitLab is lighting the fire under them, as we all benefit. Given the resources they have, it really is puzzling, they couldn't understand what was important for increasing software development productivity.

I'm guessing they heard enough of "what do you mean we can't search for commits?" from potential/existing Enterprise customers, that they realized this was actually important.