RFC: outside knotserver itself, define custom types instead of relying on go-git #387

Rationale#

I am not familiar with XRPC, but it appears that our XRPC responses use types from types/, which are defined in terms of the types exposed by external Go libraries such as go-git.

This makes it difficult to experiment with switching individual knot servers to different Git libraries, as any hashes/refs must be converted into types specific to go-git, thereby causing the entire protocol to be go-git-centered.

Current status#

• hook/setup.go
SetupRepo uses git.PlainOpen to try to open the repo.
• appview/pages/pages.go
RepoTagsParams uses a map keyed by plumbing.Hashs and a slice of object.Commits.
• appview/repo/tags.go
Repo.Tags uses a map keyed by plumbing.Hashs.
• appview/repo/log.go
Repo.Commit uses plumbing.IsHash.
• appview/repo/artifact.go
Repo.DeleteArtifact uses plumbing.NewHash.
• appview/repo/tree.go
Repo.Tree uses plumbing.NewHash.
• appview/repo/archive.go
Repo.DownloadArchive uses plumbing.ReferenceName.
• appview/repo/repo_util.go
uniqueEmails uses object.Commit.
• appview/repo/index.go
Repo.buildIndexResponse uses plumbing.NewHash.
• appview/ingester.go
Ingester.ingestArtifact uses plumbing.Hash.
• appview/commitverify/verify.go
GetVerifiedObjectCommits and ObjectCommitToNiceDiff use object.Commit.
• appview/models/pipeline.go
Trigger.TargetRef uses plumbing.ReferenceName.
• appview/models/artifact.go
Artifact uses plumbing.Hash.
• appview/db/artifact.go
GetArtifact uses plumbing.Hash.
• appview/state/knotstream.go
updateRepoLanguages uses plumbing.ReferenceName.
• workflow/def.go
Constraint.MatchRef uses plumbing.ReferenceName.
• types/diff.go
NiceDiff uses object.Signature.
• types/repo.go
  Many types here use object.Commit.
• types/tree.go
LastCommitInfo uses plumbing.Hash.

These are largely trivial and could be defined ourselves. However, it may be difficult to remain compatible with the existing protocol, unless we closely match go-git's types.

Note that, in particular, go-git's plumbing.Hash is a [20]byte, which means that protocols that use it as the hash could only really support SHA-1 hashes. This may be undesirable but perhaps necessary for compatibility with existing knot servers?

Some alternative libraries use schemes such as this:

type Hash struct {
	data [maxHashSize]byte
	size int
}