Clicking a commit quits GitX when its repository has gone away #648

Clicking a commit in the history list can make GitX disappear: no sheet, no
error, the window is simply gone. It happens with the commit details pane
loading a commit it has not shown before, in a repository whose HEAD has become
unreadable while the window was open, for example after the checkout is deleted,
renamed, or its volume unmounted.

What the user sees is the app quitting. What is logged is:

NSInvalidArgumentException: *** -[__NSPlaceholderArray initWithObjects:count:]:
attempt to insert nil object from objects[1]

Where it comes from

PBWebHistoryController.m:129 puts the current branch name into an array
literal without checking it:

NSArray *arguments = @[ commit, [[repository headRef] simpleRef], [repository refNamesHeldByOtherWorktrees] ];

That value is nil in two independent ways. -headRef returns nil when the HEAD
lookup fails, when resolving it fails on a HEAD that is not unborn, or when the
resolved reference has no name. -simpleRef separately returns nil when the
specifier is not a simple ref, so a non-nil headRef is not sufficient either.

A nil in an array literal raises rather than degrading, so an unreadable HEAD
takes the app down instead of leaving the details pane blank or showing an
error.

Scope

The line runs on every selection of a not-yet-loaded commit, so the code path is
common, but the nil itself needs a repository that opened normally and then
stopped being readable. Ordinary states are fine: a normal branch gives a simple
ref, and a detached HEAD resolves to HEAD, which is also simple.

I have not reproduced this end to end. What is verified is that the nil is
reachable by inspection and that a nil element aborts rather than degrades.
Related to #645, which is the same shape: a repository changing underneath an
open window turns into an abort instead of a reported error.

Noticed while addressing the review on #633. The line predates that PR, so it
was left alone there; the neighbouring reload call added in #633 guards with
?: @"".