[kranzky]

Things I would build:

* Push conflicted branches so developers in a distributed team can work together to resolve conflicts.

* A git-powered version of Rake, which runs only those tests that need to be run based on the git history since the last run.

* A tool to identify what code changes caused a particular test to fail, based on the above.

* Language syntax detection for smarter diffs, improving the display when blocks of code are moved around or indented/outdented.

* Language linters built in, to detect when a change is introducing a syntax error. Same for coding style.

I'd also move the "Close Pull Request" button a little farther away from the "Comment" button, and make it possible to add comments to a diff when you've hidden whitespace differences (with `&w=1`... I'd also make it a bit more obvious that you could do that).

[pbiggar]

> * A git-powered version of Rake, which runs only those tests that need to be run based on the git history since the last run.

I think you mean "magic".

That is, this is not possible :) Not that I wouldn't like it to be.

[kranzky]

Well, it is kind-of possible for Ruby/Rails. I half-built such a system once. Here's what you do:

* Gather coverage information when running tests or compiling assets.

* Use that to generate Rakefiles for running tests / compiling assets that have dependencies on the source files they would touch.

* Run the tests once, recording information about the git status of each dependency.

* When the git status of a file changes (i.e. you've just fetched some changes), mark the dependency as dirty

Even better, it you're gathering coverage data and know the test status for each commit, then not only can you show the commit that broke the build, you can show the particular part of the diff that broke the build.

Here's a guy who was trying to do some of this: https://github.com/Genki-S/ttnt