The Magic Pantry
Published in

The Magic Pantry

Proposed New GitHub Features

GitHub Universe is some kind of warehouse coding party happening now-ish.

GitHub have just released some great new features, just a month after finally allowing users to rebase pull requests, which has been irking me for years.

Like, annoying the heck out of me literally every day for five years. Aargh!

Anyway, that’s all great and everything, but there’s so much more they could be doing to improve the lives of developers everywhere. Here’s some ideas that aren’t in their roadmap but which I’d love to see.

No More Accidentally Closing Pull Requests

Come on, seriously?

These buttons are too close together, and I’ve seen many pull requests accidentally closed and immediately reopened again as a result. Ideas:

  • Make the “Close and comment” button red and frightening; or
  • Move it way over to the left-hand-side, out of harm’s way; or
  • Turn it into a checkbox which toggles the lone submit button from a green “Comment” button to an angry red “Close and comment” button.

Ignoring Whitespace in Diffs

So hidden. So useful.

You can append “?w=1” to a diff URL to ignore whitespace changes, which makes diffs much easier to grok when they contain reformatting changes, such as moving some code into a conditional block and indenting it all nice and kentucky. Great, right? But it’s a bit of a secret, and it disables inline commenting. So…

  • Make this an easy-to-discover toggle in the UI; and
  • Allow the user to set a default value for the toggle; and
  • Make sure that inline comments can still be made when reviewing pull requests that have their diffs set to ignore whitespace, it’s really annoying that I can’t do this why can I not do this.

Time-Lapse Blame View

I really miss being able to do this. That’s P4V btw.

I love this feature from the Perforce Visual Client. It allows you to scrub across the history of a file, getting realtime, colourised updates of what’s changed. GitHub totally have to steal this idea, it’s awesome. Their version would be sooo much better. Atom, their Sublime Text rip-off, proves the point. Anyway…

  • Show a “git blame” view for an individual file in a particular branch.
  • Quickly identify the user/commit/date/pull request/tag for each line.
  • Colour each line to show how recently it was changed (or deleted).
  • Focus the view by sliding a scrubber to select a range of commits, which instantly updates the view, fading colours in and out and stuff.

Pull Request Linkage

As a follow-up to the previous suggestion, what I want to be able to do very easily is push a change to a branch that fixes some bug, then view my pull request, scrub across the diffs to find out whose code I changed, then quickly add a reference to the pull request that introduced their change so I have a nice two-way history of where a bug was introduced and where it was fixed.

This could almost be done automatically; showing links alongside a pull request to all related pull requests, based on what code has changed, and allowing these links to be pinned if we want to save a two-way link.

Collaborative Conflict Resolution

Kaleidoscope is great, but going solo when resolving conflicts can be hard.

Properly resolving conflicts is perhaps one of the hardest parts of using Git and is a big source of bugs. This problem can be mitigated by good process somewhat, but it’s a common site to see a handful of developers gathered around a monitor scratching their heads as they try to figure out how to get the damned thing merged and shipped so they can go doon t’pub.

GitHub should capture the essence of this experience for remote teams:

  • Add a new view, similar to a pull request, for resolving conflicts when merging one branch into another. This should automatically create a new branch for the changes that resolve the conflict.
  • Show this new branch as the centre pane of a three-way merge view so it can be discussed. Just like the diff view for a pull request. But one better.
  • Notify all developers who are responsible for implementing conflicted code to get them involved to help resolve the conflicts.
  • When approved, merge this new branch with a commit message that lists the conflicts and includes the #id of this conflict request thing so we can always trace back to understand what was done and why.

Forced Push Management

As a follow-up to the previous suggestion, another big source of bugs I’ve seen in the past is when a branch needs to be force-pushed to revert some heinous problem, and then another hapless developer pushes an old version of the branch which re-introduces the problem, when they really should have done a hard reset to the origin branch first. It would be great if this could be marked with a special empty commit or tag or something so that GitHub could block any pushes that don’t contain that commit, and block fetches with a message saying a hard reset is required first.

Or something. I’m getting sleepy here.

Automatic Back-Merges

Git flow started it all.

Many of us use a well-defined branch naming and merging process. Often this means requiring developers to back-merge changes into their own branches. Pull requests already indicate when this is necessary, but the longer developers wait to do the back-merge, the more likely it is that they’ll need to deal with conflicts.

  • Automatically merge changes from upstream branches in open pull requests, if there are no conflicts.
  • Create one of them new fancy “collaborative conflict resolution” thingies I invented above if there are conflicts, and notify everyone involved.
  • Allow the repository to be configured to know about branch naming conventions and the direction of permissible merges, and then run this automatic process even when no pull requests exist between the two branches (for example, between master and develop). Hmmm, this point almost deserves a heading of its own.
  • Now that we know a bit about the branch/merge workflow, notify developers if they push a change to their branch that will conflict with somebody else’s branch if both branches have a common base, because the workflow dictates they are destined to be merged together at some point in the future. Handy!
  • And even if the changes wouldn’t conflict, let the developers know if they’re working in the same bit of code as someone else, and that maybe they should start collaborating with them or at least talk to them about what they’re doing or just add a :sob: reaction somewhere.

Automatic Placeholder Pull Requests

As a follow-up to the previous suggestion, if GitHub knows about the branching and merging convention used for the repository, then it should be possible to create pull requests automatically, the first time a commit is pushed to a new branch. This would be useful for announcing new work and tracking changes made during development, allowing collaborators to comment before the work is complete and ready for review.

Language-Specific Diffs

OK, I’m running out of steam here and you probably won’t ready this far anyway (I mean, I know you have read this far; I mean the average person will have given up long ago. If there’s one thing I know about you, it’s that you’re better than average). All I’m trying to say is expect no more images and crazier ideas from here until the bitter end.

  • When viewing the diffs for a file written in a known language, enable syntax highlighting.
  • Use the syntax of the language to make better decisions about which parts of the file were added, modified or deleted. Man, it annoys me when diffs don’t respect code block boundaries. It’s like, sure I deleted that } from a perfectly logical position just so I could replace it with that completely random } from the middle of a bunch of code I deleted.
  • Make it easy to view sections of code that were moved without being modified. If they were moved and modified, then highlight just the bits that were added, modified or deleted.
  • Make it easy to view files that were renamed without being modified (and again highlight just the modified bits if there were any.
  • In fact, someone should start a company just doing this, you’d make $’s.

Magical Bisect Build Blame Thing

This is just a dream I have. It requires something a CI server, like CodeShip or Semaphore. It requires something that measures code coverage, like Coveralls. It requires something that knows what changed between the last green run and the current run, like GitHub. And it could optionally include something for speeding up builds by only running tests which are known to exercise the changed code (like, ahhh, good-ol’ make depend).

Anyway, what happens is this.

  1. A developer pushes a commit. GitHub triggers a build, possibly passing along some information about what changed since the last green build.
  2. The build fails. The code coverage report is combined with knowledge of the failed tests and knowledge of what changed since the last build to magically identify which bits of code broke which tests.
  3. GitHub uses this information to create a new branch and pull request for fixing the build failure, notifying everyone who made changes that are known to have broken tests, and highlighting which bits of code broke which tests (with the test code highlighted too). It locks the broken branch, preventing all other changes until this new fix request thing is building green and has been approved and merged.


In fact, someone should start a company doing just that, too. You’d make $’s.

OK, I’m properly tired now.

The End.




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jason Hutchens

Jason Hutchens

Procrastinating perfectionist.

More from Medium

Using cron to neatly automate tasks

Introduction Image containing a clock and some code

Getting-init Some Basics on Git and GitHub

Screenshots using Chrome developer tools

Screenshots using developer tools

GitHub: Understand issue close keywords with experiments