[ngoldbaum]

Wow, github doesn't handle big diffs well. Some sort of automatic pagination would really help.

[TazeTSchnitzel]

GitHub does cut it off beyond a certain point, but that cutoff point should be much, much earlier.

[foz]

Github handles it well, but our browsers don't. It would be nice if they loaded large diffs progressively, as you scroll.

[bpicolo]

Github is a website, it's it's job to make the browser handle it well.

[cratermoon]

I would make the case the "big" diffs are a problem. Unless there's a really good reason (and bad dependency management is not a good reason) then commits should be smaller and more logically related.

[rcthompson]

This is a merge commit, which means the diff is going to include all the changes on the branch being merged. Even if all the individual commits are small, a merge diff can still be very large.

[serf]

While I agree that a big diff isn't a good idea, I disagree with the notion that one should develop in such a way that makes Github (or whatever VCS you're using) work right.

I don't think working within the capabilities of the VCS you're using should ever be a priority for a software development effort; rather I think the VCS's priority should be to allow for their use within most contexts of software development. (the other way around)

[kasabali]

" This change deletes the C implementations of the Go compiler and assembler from the master branch." is logically related as it could be. Everybody has a different interpretation of it, I guess.

[teraflop]

It's a merge commit, so naturally it's going to have a huge diff even if the actual work was done in much smaller increments.

[andrewchambers]

Because he automatically translated all the code using a tool.