Closed redrabbit closed 6 years ago
After experimenting for a while, I'd say that this is not really relevant.
It is feasible to implement node ids for all GitObject
types by creating our own global id as follow:
"#{repo_id}:#{String.slice(oid_fmt(obj_oid), 0, 7)}"
resulting in, for example, GitCommit:2:bba34c5
or R2l0Q29tbWl0OjI6YmJhMzRjNQ
(Base64).
But I did not find any real use-case here. Having the possibility to fetch a repository by node id and use the Git OID to retrieve the right GitObject
is not that cumbersome...
Currently, a
Repo
provides following reference related fields:head/0
- returns the HEADGitReference
for the repository.ref/1
- returns theGitReference
object matching the given full-name or shorthand.refs/0
- returns allGitReference
objects for the repository.refs/1
- returns allGitReference
objects matching the given wildcard full-name.It also provides following function to fetch a single object:
object/1
- returns aGitObject
matching the given revision.A
GitReference
can fetch it relatedGitObject
usingobject/0
. TheGitObject
type being an interface, it can be cast toGitCommit
,GitTree
,GitBlob
. For example:A very neat feature would be to have the possibility to retrieve
GitReference
andGitObject
using a Relay Global Object Identification Specification:This is already implemented for
User
andRepo
but needs more work to implement for Git types. This issue depends on how the Git storage backend (see #2) is implemented...