Reviews

Warshall has its own review window, separate from pull requests on a hosting site. It holds the project's commit history, the reviews on the project, and a diff that shows the whole file around every change.

Opening the window

Press Reviews on the top bar, or the same button in the header of the Terminals view. The window opens over the workspace and names the project it is showing. The arrows beside the project name step to the next project. Escape or the close button closes the window.

The window also opens by itself when you look at a commit from somewhere else.

• Clicking a commit in a git popup opens that commit's changed files here.
• Clicking a changed file in a git popup opens its uncommitted changes here, under the heading Uncommitted changes.

This is on purpose. The editor shows your project's own files, so a commit made in a terminal's own checkout is read here instead.

The tabs

Commit history

The rows are the project's commits, newest first, across every repository the project is made of. From left to right a row shows the requirement it was filed under, the review that covers it, the repository when there is more than one, the commit subject, the date and the short id.

• Click the requirement to see that feature's card in a popup.
• Click the review to open it, with a Back button that returns to the history.
• Click the subject to see that commit's changes in the same window.
• Click the date to switch between a relative date, such as 3 minutes ago, and the full date.
• When the project's origin is on GitHub, the short id links to the commit there.

Three filters sit above the list. All workstreams and All features narrow the list to one WorkMap path or one feature. The third picks which branch the history is read from, and it leaves out the branches the terminals create for their own work. The count beside the filters says how many commits are listed. The history goes back 150 commits.

While the history loads the list reads Reading history…. A folder that is not a git repository reads Not a git repository, and filters that match nothing read No commits match.

A review

The two review tabs show the list on the left and the open review on the right. Each row shows the requirement the review belongs to, the review id, which starts with PR-, and the title. An empty list reads nothing sent out yet or nothing waiting on you.

A review has four sections, Description, Code, Comments and Reviewers.

Description shows the review id, the title, who opened it, its status, and the description itself as Markdown. On your own review you can edit the title and the description in place. Click either one and type. The title saves when you press Enter. The description saves on its own a moment after you stop typing, and Confirm saves it and closes the editor. While it saves the top of the section reads saving…, then saved with the time. An empty description reads no description.

Comments, reviewers and the model walkthrough are covered in Comments and teammates.

The diff

The Code section is one column, with the line number, a plus, minus or space, and then the line. Beside it is a tree of the changed files, and clicking a file takes the diff to it.

The diff is read with the whole file, not just a few lines around each change. You see the file, with six lines kept around every change and long unchanged stretches folded away.

• A fold at the top or bottom of a file says how many lines are above or below it.
• A fold in the middle says how many unchanged lines it hides, with a control on each side that shows ten more.
• After a few clicks on the same fold, an expand all control appears.

Each file has a header with its folder and name, a badge for a new, removed or renamed file, the counts of added and deleted lines, and a copy control. The copy control copies the whole file as this change left it, never the diff alone.

Some files show as what they are rather than as code.

• Markdown, SVG, HTML, LaTeX and notebooks have View Rendered and View Source on their header. SVG files and notebooks open rendered, and the rest open as source.
• Images, PDFs and Word documents have no text to compare, so they are always shown rendered. A changed image shows the version before and the version after.

A rendered file is always read at the commit, so it shows the document as it was then.

Large changes

A change with many files is split into pages by how much changed, with page numbers and arrows to move between pages. A file's lines are only loaded when its page is shown.

Some files are not shown in full.

• A very long file is shown without syntax colors.
• A file with more than twenty thousand changed lines is not loaded and reads file too large to display.
• A file cut short says file too large, view cut off.
• A file with no text reads binary file.
• A rendered file larger than 25MB reads file too large to preview.