New

Instead of focusing only on replicating features that could be found on GitHub itself (even if it's necessary to avoid going back and forth between both platforms), from time to times we try to add small things than, when added up, can make the whole experience a lot better.

This time it's about code review, a big part of the IssHub platform.

We already saw here how a pull request evolves in time and how we could mark some parts of the code as reviewed.

Mark code as reviewed

But what is "reviewed" anyway? Did I see this chunk of code? Did I validate it? Rejected it?

There were no way to know... until now.

Now, for each chunk of code (and remember than you can still split a chunk into many), you have many choices:

• not reviewed (by default, or you decided to mark it that way)
• ignored (the chunk will be collapsed)
• not sure (you did a pass on it but are not sure yet if you accept it or not)
• refused
• accepted

You can of course do this for a whole file instead of doing it chunk by chunk. What's also new is that by doing this chunk by chunk, the review status of the file is updated, and you even have a review progress bar for the whole pull request:

In addition, you can filter the files to display depending on their review status, and even update the review of many files at once, using the top right menu:

And you can easily filter the issues list to display only the ones you started to review:

Mark comments thread as read/waiting

Often, a review consists of multiple passes from the reviewers and the author, with comments, grouped in threads related to some lines of code.

We added a simple way for you to keep track of the threads you read and the threads you expect an answer.

This way, the next time you'll go on the pull request, you can ignore some threads and focus only on the work to be done:

And you can easily filter on issues where you have something new to read:

Other improvements

Of course among these two big new features, we tweaked a lot of things. For example:

• Pass the mouse over the number of files touched in a pull request/commit and you'll the kind of files that are touched. Useful to know if you only want/have to review JS and the code is only related to CSS:

• By pressing "s" while on an issue, you'll have the issue taking the full with of the screen. Useful if the code to review has long lines. You can now reduce the sidebar containing the list of touched files, to have even more horizontal space

• You can now group pull requests (in the list or in the board) by status check or review status

• In no-details mode in issues lists, the pull-request icon is displayed to easily make the distinction between issues and pull requests

• You can open many commits at once in tabs, instead of clicking on each one

• You can hide a comments thread if it bothers you to full read the code around this thread (it's the case by default if a thread is marked as read by you, without any new comments)

• You can go to the start or the end of a thread

~ The end ~

New

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.

New

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.

New

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

New

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.

New

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

First, we managed the whole www.isshub.io 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

New

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:

http://isshub.io

New

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.

http://isshub.io

New

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 :-/

http://isshub.io

New

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

http://isshub.io