Instead of reading History off of a Commit object, you can read its oid field which will be the commit SHA.

query ($repoOwner: String!, $repoName: String!) {
	repository(owner: $repoOwner, name: $repoName) {
		defaultBranchRef {
			name
			target {
				... on Commit {
					oid
					messageHeadline
				}
			}
		}
	}
}

It feels super weird to cast at unrelated struct into a git.Commit object in Go. I would rather copy the fields manually:

return &git.Commit{
  Sha: ...,
  Title: ...
}, ...

It's unfortunate that now the api package has to import (and thus depend on) the whole git package just so it can return a git.Commit type. Ideally api and git packages should be entirely separated concerns, unaware of each others' existence. I have some ideas how to iron this out, but I don't think it's time yet, and since this isn't a pressing issue, let's leave this like it is and circle back later.

OK, I see what you're doing here and it's a solid start, but I wonder if we can make this even more simpler & straightforward for the runBrowse() implementation. Right now, swapping out implementations of LastCommit like this is kind of awkward. Even though we pass around and assign funcs to struct fields quite often in gh codebase, I'm thinking that it has gone too far and that we should replace this approach with interfaces instead.

Ultimately, runBrowse() doesn't need to know about the type of lookup that will be performed. The only thing it wants to know is: what is the last commit for this repository? Of course, the definition of what "this repository" is ultimately depends on the --repo flag, but runBrowse() ideally should not be aware of whether --repo was used or not.

I propose to pass a concept of a "git client" to runBrowse via its opts struct. Something like:

type BrowseOptions struct {
  GitClient gitClient
}

type gitClient interface {
  LastCommit() (*git.Commit, error)
}

What implements the gitClient interface? Right now there are no implementations, but you could create some:

1. The first and obvious implementation is the one that consults git.LastCommit() and therefore reads from the local git repository of the current directory;
2. The second implementation is the one that uses api.LastCommit(httpClient, repo) to fetch commit information from the API.

Either of these implementations could be assigned to opts.GitClient by the command's RunE block based on whether or not the --repo flag has been passed. Then, runBrowse() can consume from the git client without knowing what type of a git client that is or where it reads from.

1. If there was an error, that error should be surfaced to the user and the command aborted. Is there a reason to intentionally silence it?
2. What are the cases when commit == nil?

Oops, commit should never be nil if err is nil.

I only silenced the error because that was how the code was before:

5bdaab8

I think it might be silenced because the git error wouldn't be understandable.

fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
/usr/bin/git: exit status 128

Edit: if the retrieval part of LastCommit fails, maybe we should return a custom message, that way we can return err?
git.LastCommit: "a previous commit could not be found for this repository"
api.LastCommit: "a previous commit for OWNER/REPO could not be found"

One nice thing about GitClient now being an interface is that you can pass any fake implementation for tests, as long as it satisfies the interface. You can make a test git client that returns a static commit information on LastCommit without having to look it up over either HTTP or by shelling out to git. Then, you don't have to stub either HTTP calls nor git calls in tests anymore 🎉