technoweenie

https://tangled.org builds on atproto for the social features.

I'm really happy to see large file support in Git core. Any external solution would have similar opt-in procedures. I really wanted it to work seamlessly with as few extra commands as possible, so the API was constrained to the smudge and clean filters in the '.gitattributes' file.

Though I did work hard to remove any vendor lock-in by working directly with Atlassian and Microsoft pretty early in the process. It was a great working relationship, with a lot of help from Atlassian in particular on the file locking API. LFS shipped open source with compatible support in 3 separate git hosts.

I just format the message in my text editor and paste it back into the commit message box before submitting.

> Realistically how many hours of work went into this upgrade process then?

Eileen wrote about the actual process a year ago when GitHub upgraded from Rails 3.2 -> 5.2: https://github.blog/2018-09-28-upgrading-github-from-rails-3...

FWIW I've always heard it described as a thundering herd. Though, your description is spot on, according to Wikipedia [1]. The problem the article discusses is called a cache stampede or dog pile [2].

[1] https://en.wikipedia.org/wiki/Thundering_herd_problem

[2] https://en.wikipedia.org/wiki/Cache_stampede

I wouldn't fault anyone for getting these similar names mixed up though.

Groupcache is one implementation in Go. However, it uses its own in-memory cache on your app servers instead of an external cache service.

https://github.com/golang/groupcache

https://news.ycombinator.com/item?id=6121501

https://talks.golang.org/2013/oscon-dl.slide#43

We typically run go's built-in server behind nginx. There's no need for something like gunicorn in go.

The first time we announced svn support, it WAS a joke: https://github.com/blog/31-back-to-subversion

GitHub also supports txt and other common document formats: https://github.com/blog/2061-attach-files-to-comments

Here's as close to an official response that I've seen publicly: http://www.quora.com/Why-is-GitHub-for-Mac-not-open-sourced/...

Correct. Though I wouldn't say the company is any less remote friendly than it used to be.

How do you handle a custom GOPATH like that when the current repository needs to be in there too? We've tried manually symlinking the repo dir into the custom '$GOPATH/src/github.com/user/repo' dir, but it feels really hacky.

Migrations stay pretty small. Most of them just add a column or index. We also have to make sure tables aren't too hot to migrate. See a previous post for more on that: http://githubengineering.com/using-mysql-performance-schema-...

It's also really important that migrations don't affect the running app code. New columns shouldn't be used yet. Removed columns or tables need to have all references removed first before running the migration. We confirm this with a deprecation helper that sends metrics to Graphite.

That's about all I can answer from the app side :)

That's just a special staging server for Venture Brothers nerds (no one else wants to type all that out).

Yes, that's really important for the Git LFS project to us. Of the languages that we're comfortable with, it's the only one that met that requirement.

I feel like there have been a lot of blog posts and HN discussions about the merits and downsides to Go, and I don't really have anything new to add to that.

I honestly hadn't seen git-bigstore. Git LFS started out as a Git Media update, actually. We changed the name pretty late in the process so that it didn't clash with existing Git Media repositories. Go was picked so that we could ship static binaries so its users don't have to worry about installing the correct ruby/python runtime and 3rd party dependencies.

Git LFS isn't tied to any specific service either. You can install our reference server somewhere, and start using it with your GitHub (or any host really) repositories without having to sit in our wait list or pay us a dime. Though our reference server isn't really production ready, so I wouldn't advise that for real work just yet :)

I think the main take-away with this post is that static sites for docs are awesome. GitHub uses [nanoc](http://nanoc.ws/) for the [API documentation](https://developer.github.com/).

The only downside of hosting static text on GitHub Pages without Jekyll is that you have to push the generated HTML too.

Imagemagick can convert a PSD into a PNG.

Work has started on the move to 3.2: https://twitter.com/charliesome/status/511517393038753794

We use MySQL with ActiveRecord primarily (with a few exceptions). So that's all Users, Repositories, Issues, etc.

Git data gets stored with Git on separate file servers.

The query annotations show up as a mysql comment next to the query. I don't know if we have any automatic indexing of the annotations themselves.

We try to stick to ruby/rails since so many people are comfortable in that environment. We try to balance the desire to break pieces out with the fact that it lowers the number of devs qualified to work on it.

> Basically, what makes GitHub's process different to the decades-old "grep the slow query log and run an EXPLAIN"?

Sam's chatops tools opens this process up to a lot more people that otherwise wouldn't be comfortable logging on to servers to access the slow query logs (assuming that they even have access to the servers). It's a great way for app developers to level up their sql skills from other more experienced coworkers.

The impact of slow queries determines their priority. How frequent are the slow queries? Is it from a background job, or does it cause exceptions on important pages or API calls?

I don't know if this process is streets ahead of what other companies have, but it's made a hugely positive impact on our MySQL infrastructure.

Riak Search will do this for you. The Riak key/value store also has post-commit hooks that you can use: http://docs.basho.com/riak/1.2.1/references/appendices/conce...

Whatever happened, happened. There's no rebasing involved. There's just a lot of jumping around to various tags at different points in time.

It will be available at https://atom.io. It's not quite ready, but you can see a screenshot here: http://discuss.atom.io/t/linux-build-screenshot/6317

I don't know anything about popcorn app specifically, but you'll normally see a message (instead of a 404 page) if GitHub removed a repository.

We use Kestrel for our internal hooks delivery system also (based on jnunemaker's suggestion).

Nope. You're free to use whatever you want on your own pages (Google Analytics, Gauges, etc).

For what it's worth, we have an API endpoint that has had the right IP network listed ever since it went active. If you _need_ to verify IPs for whatever reason, use this:

http://developer.github.com/v3/meta/

Oh right! I meant to say Go vs Node.js. Only one walks away.