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.

It's also possible the Wikipedia article is maintained by someone with a stronger opinion about the definition than would be reflected in the typical person using the term.

I'd hope so!

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.

But this would not work in this set-up right? Wouldn't the user facing server (in your case Nginx) have to be the one that serves over HTTPS?

I'm a bit confused about this package.

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

Ah, that's a recent addition. Thanks for the pointer. Does it work for bugs? The post mentions pull request comments.

Yes. It works on issues too.

I wonder why they have restriction based on file extension in place, it's just inconvenient that you have to rename .patch to .txt only for the UI to accept it.

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.