rtomayko

Just wanted to note that a fork is automatically created and a pull request created when you edit a file in a repository you don't have push access to. So the workflow is even simpler: 1.) see file, 2.) edit file and save, 3.) land on send pull request page.

As a first measure I think we could make it so that once you removed yourself as a collaborator from a project, it would not be possible for the person to re-add you. I realize that's not ideal but would be much more trivial to implement than UI / additional server state for confirmation before being added.

I'm the GitHub employee that fixed the bug. I usually try not to get involved with stuff like this but I feel like I'm in a unique situation to correct the record here.

"They purposefully allow this glaringly obvious mechanism for insulting and annoying their members and are actually involved in the joke."

I've never heard of the joke. I've never heard of anyone at GitHub being involved in one of these jokes.

There has been one case that I'm aware of where someone mass added people to a repository in order to fill up activity feeds. That person was banned. It's an issue we'd like to address more generally.

"Until I broke their server they were all laughing at my 'testing' then they were pissed when they had to fix the bug I found."

I fixed the bug without being aware of any of this. I check our exception monitor every day. It was there. It was obvious. I fixed it.

It was a simple bug triggered by branch names that look like commit SHA1s. Here's the commit:

https://gist.github.com/88bc774d0c97e6c955c0

It affected only branch list pages with branch names matching [0-9a-f]{40}.

"If you don't believe me, look at the HackerNewsTips twitter account, which I know is astroturfed by a github employee."

That is not a GitHub employee. We don't hire anyone that witty as a rule.

There's a list of short aliases enabled in git-sh by default here:

http://rtomayko.github.com/git-sh/

Best case you have to do three RTs for a full SSL handshake (without false start anyway), so a RTT of 300ms will bring you pretty close to that 1000ms. We (github.com) certainly have average 1000ms SSL handshakes in Asia -- we're 5 RTs for an SSL handshake presently. It's extremely annoying.

FWIW, I was copied on an email exchange with Brian Kernighan regarding the piece and he referred to AWK as "Awk". Thought you'd like to know :)

GNU's is "Awk" but the language and most early implementations are referred to as "AWK" from everything I've read. More here:

http://en.wikipedia.org/wiki/AWK

Me too :) Actually, check out the talk mentioned at the beginning of the essay. Pretty sure I build that exact pipeline at some point near the middle.

Updated. Thanks!

It's not. The primary profile email is used currently:

https://img.skitch.com/20110426-gjj8fcrdmayyinfgb57bgtgcns.j...

That's an interesting request though. This isn't the email I have configured in my ~/.gitconfig either.

Well said. When I talk to people at conferences and whatnot about GitHub, they're often surprised we run a core git stack with few modifications. Repositories are stored as plain old git repositories and we use git's normal command line interface for many types of operations.

It really is a testament to git's design (and I think maybe classically designed UNIX programs in general) that we've been able to do so much on the server with something designed mostly for local command line interaction.

People still talk about git's "lack of extensibility" (i.e., no library / you can't write extension programs in Python) but I've found that the "write programs that do one thing" model lends itself extremely well to all kinds of unplanned and novel uses.

omg please turn development mode off antirez. Are you trolling me?

On github.com, many types of requests can result in one or more calls to git commands. Every ms we can shave there can have a pretty big impact on response time.

Can you dump some ping times? 2-4s is waaaay outside of what I'd expect the average response time to be.

"Bare metal" as in "not-a-VM", yeah.

Where are you located (geographically)?

We have a couple developers more or less dedicated to performance at this point, and we're moderately satisfied with server response time for most areas of the site (the issue tracker is a notable exception -- we're working on that).

I ask about your location because we also have some latency issues as you move further away from the US east coast (Wash. DC) datacenter. We're working on that also.

Would you mind maybe submitting the output of `ping github.com' and any other pages you find intolerably slow at http://support.github.com/ ? If that's too slow just dump stuff here I guess.

Same :)

They're not.

Here's a few review threads in the wild to illustrate:

https://github.com/legalbox/lb_js_scalableApp/pull/1 https://github.com/jnicklas/capybara/pull/271 https://github.com/gem/openquake/pull/25

EDIT: formatting.

Yeah, exactly. We (GitHub) use reflogs on the server, so everything that was pushed was in the repository and can't be gc'd out for at least 90 days. The master branch ref was just pointing at the wrong commit due to the forced pushes.

Yeah. It's definitely not a heroku issue. We were configured to run on a single backend. It's since been increased and should be better now.

Okay. The session cookie is marked secure and is sent only in response to HTTPS requests. That should cover everything.

We fat fingered the config. The cookie is marked secure now but we found another issue where it's being sent back on redirected HTTP requests. It should be all plugged up in a bit.

I have a great way of dealing with this that's simple, fun, and requires very little lead time: get drunk.

I head out around 10PM and drink beer or whisky repeatedly until I'm completely intoxicated. By 2AM or so all I want to do is go to sleep.

That's fucking ridiculous and the stupidest thing I've ever heard of in my life.

Except none of that stuff was indexed by google at time of writing. The links that were added to Wikipedia after the article was published made your search possible:

http://en.wikipedia.org/wiki/Talk:Hyperlink#what_does_href_s...

Trust me. The whole reason the article exists was because there was no clear answer through search/wikipedia/w3c/etc.

Funny how these things work:

http://img.skitch.com/20100806-n839s48kxx3gq6ae3m7ru45t6j.pn... http://img.skitch.com/20100806-dy2ghicjxgac7dpmdd2pwhdntc.pn...

The GitHub homepage had support for the Konami code with the commercial launch, IIRC:

http://github.com/site

> GitHub rocks, it has really changed the contributor attitudes for my main project, I am a paying customer (another account)

Thanks!

> and just really hope you guys are around a long time!

We'll be here. It's a profitable business with a straightforward model and we intend to keep it that way.

That's mostly correct. We use the email addresses provided in the commit Author and Committer fields and correlate them with the email addresses associated with GitHub user accounts. The commit Author/Committer email addresses are also used to fetch gravatar images even when no GitHub user account exists for the email.

It's trivial to spoof these fields using the --author argument to git-commit(1), by setting the GIT_AUTHOR_EMAIL/GIT_COMMITTER_EMAIL environment variables, or by setting a different name/email using git-config(1).