See pull requests code evolve in time, and other things

Over the past few weeks, we focused on pull requests. We already had enough tools to make the life of reviewers easier, but we knew we could do better.

First, now that Github moved their GraphQL API out of beta, we could activate the Github review system by default for every repository.

And we also integrated the "request review" feature from Github, with some small additions:

  • filtering, with a default filter to easily see for a repository which pull requests you are requested to review
  • a board view, so it's easy for a manager to see who is expected to work on which part, and it's easy to change the requested reviewers of many issues at once

But the main features we added are: pull-requests states, and diff modes.

You know what's worth a thousand words? An image... So we'll use screenshots, by explaining them, to discover these two features.

Let's say you are in a repository and you see this in the activity feed:

It says that the content of this pull-request, ie the code, has changed.

You have some interest in the issue solved by this PR so you open it and go to the "Files changed" tab.

You now see this:

It seems like nothing changed except this little box on top of the files list.

Let's zoom in:

Yes, you read and understand correctly. You can see previous states of the pull requests, and compare between states.

A "state" is a version of the code of a pull request. It's not rare to update a pull request after our first push, for example to add more work, or simply after a review.

These states are helpful to see how the code evolved in time.

Let's see the very first state:

It will open a new tab in the pull request, showing the same "Files changed" view, but back in time:

The block presenting the state reflects where (when...) we are:

Now that we seen how the first version of this pull request was, let's be curious and see how it evolved.

The first step is to compare this first state, with the second one:

Again, a new tab will open, but this time, only the changes between the two states are shown:

We can see that there is only one file that was changed after the first push. It seems to be only spaces, though:

If I'm not interested in reviewing space changes, there is a solution.

Let's open the menu:

And click on "Attenuate white space changes".

The result is this:

We can still see the "-" and "+" showing what changed, but as there are only white-space, lines are not colored.

But it's now hard to read. It could be ok in some cases, for example a single line added, etc, but not here. We could use a "two-panes" diff....

Oh wait, remember the menu with the "Attenuate white space changes" and the hidden entry?

Let's unveil it:

Yes, a new mode. Let's click this "Display two-columms diff" menu entry.

The result is this:

We can now, on each side (left is "previous version", right is "new version"), read the code.

Ok so I read this, and now I want to see the next change.

To help you doing this faster, we included arrows in thte block presenting the state. Block that, in this "compare" mode, display the two states being compared:

Here there is no additional information about each states, which means that they are all based on the same branch (the branch for which the author wants the pull request to be applied on), on the same version of this branch. But:

  • If the branch changes between two states, the two branches (before/after) will be shown.

  • If the branch is the same but not its version (the HEAD commit), it's because a rebase was done, and it will be indicated.

On the left of the two states, we can see an arrow. We are comparing states 1 and 2, and this arrow allows you to see the next step: the comparison of the states 2 and 3.

Of course then you'll have the sam arrow, and a left arrow to see the comparison between states 1 and 2.

~The end~

It's the end of the presentation of these new features that, we hope, will ease your work with pull requests.

Invite your coworkers

If you are the administrator of an organization and you, or some collaborators, are using IssHub, you may find useful to invite other collaborators to use IssHub with you.

For this, to to "Your account", select the organization in the list on the top, and click on "Invite collaborators".

Now, simply fill the form, send it, and wait for your team to join!

If you're not the administrator, you can do the same by using the "invite some friends" button.

Win free subscriptions slots

Do you feel you could use IssHub more but are not willing to pay - or pay more - for now?

We have the solution for you: our referal program.

It cannot be simplest to use: go into your account, get the link, share it, and for each person subscribing to IssHub by following this link, you'll earn a lifetime-free subscription.

For this, simply go to new "invite" page on your account and you will:

  • find two referal links (one for the website, one for the application) that you can share the way you want
  • a twitter button to easily send a tweet to share this link
  • an email for to invite friends, with the referal links included, of course


When preparing our website to be out of private alpha mode (we're now live!), we added an interesting thing: sponsoring.

Any person, or organization, can sponsor a repository, for a small fee (see our plans).

By doing this, any person using IssHub can now subscribe to this repository for free.

For example, an organization could sponsorize one of its open-source repository, so any collaborator (member of the organization or not) could use IssHub to manage its issues and pull-requests.

And to let people now who their benefactor is, in the application, the sponsor is displayed near the name of the repository.

In addition, on the subscriptions page, there is a new tab dedicated to sponsorized repositories.

A handful of small enhancements

It's been a while without updates. But, believe us or not, we were at work more than ever.

First, we managed the whole website, including account management, plans, subscriptions.

Then, we made a lot of speed up of our backend: operations are now a lot faster.

And finally, we still worked on the app. Mainly:

  • The notifications menu was enhanced and it's now possible to manage an issue notification from the issue itself
  • Admins of organizations can now manage subscriptions for their members
  • Github projects changes are now displayed in activity feeds (project/column/card creation/edition/deletion)
  • Pull requests are greatly enhanced, but this will be for a next update

Reviewing becomes even more easier, again

A few months ago, we made reviewing easier, then even more easier.

Oops, we did it again!

The first step was to be able to mark, in a pull-request, a whole file as reviewed. So you could ignore it in the next steps of the review process, at least if it was not modified in between.

Then we added the possibility to do it for "hunks", ie parts of a file that where modified.

But, as reviewers ourselves, it was not enough for us, so maybe for our users.

For example a new file could be added, so with only one hunk, that could be long, and with only a small part that you wanted to comment, be you had to let the whole file as "not reviewed"

Same for a file with many hunks but a big one.

Now, in one click, you can split a hunk in two.

For example, for a new file, split a few lines before the part you do not agree with, and a few lines after, then you can mark the first and third hunks as reviewed!

And deleting a split is as easy: a single click.

Here are some screenshots:

Over the line you want to split on:

Click the split button:

A new hunk separator appears, marked as "manual split"

You can do the same a few lines below:

Then mark the first and third hunks as reviewed, and comment on the second one:

Protecting your writing

On Isshub you can create issues and, mainly, write comments.

And as for any text, typing and having your prose lost by a manipulation can be really frustrating.

It was easy to encounter this problem on Isshub until recently: start typing a comment and, for any reason, load another issue: the currently loaded issue is replaced with the new one, vanishing your text before you can do anything.

This is not a problem anymore!

Textareas are now "protected": as soon as you do something that may lead of to such a loss, a modal will tell you about it with:

  • a readonly textarea with your text ready to copy in your clipboard (already selected and focused, you just have to copy it)
  • a text: "You currently have text in a textarea. By continuing you may lost it."
  • a question: "Do you want to continue anyway?"
  • a button saying "No", that will abort your action and take you back to your filled textarea
  • a red button saying "Yes, continue", that will do your action, that may lead up to the lost of your text. But now you have the choice.

Diff inception

During review, you may ask for the author to update its pull request.

So they do some work then they have two choices:

  • they add a new "fixup" commit, to be fixed-up/split/squashed with previous commits at the en of the review
  • they directly update the previous commits

In the first case, you are lucky, you can click on the commit and see what's modified.

But in the second case, it can be very difficult to see what the author changed, especially if the commits are big ones.

Introducing "commits comparison"

On the list of commits of a pull request, if we detect that a commit is a different version of another commit, a new button "Compare with" will be displayed, allowing you to compare these commits.

What does it give you? The exact same view as if it was a new "fixup" commit: you see exactly what changed between those two commits, and nothing else

Only caveat: as it's not a real commit you cannot comment on it :-/

About pull requests branches

A few little things where added today about pull requests branches:

  • the head and base branches are clickable: you'll be sent on Github on the correct tree
  • if the base branch is not up to date, it will be indicated (time to do a rebase)
  • if the PR is closed and the head branch is not deleted, it's possible to delete it in one click right from the PR view

History of opened issues

It is now possible to navigate between opened issues via the browser history.

The place where the issue was opened is respected: in the right panel or in a modal.

No published changelogs yet.

Surely isshub will start publishing changelogs very soon.

Check out our other public changelogs: Buffer, Mention, Respond by Buffer, JSFiddle, Olark, Droplr, Piwik Pro, Prott, Ustream, ViralSweep, StartupThreads, Userlike, Unixstickers, Survicate, Envoy, Gmelius, CodeTree