Fast implementation of Git in pure Go
codeberg.org/lindenii/furgit
git
go
README: Repository gets new methods
+22
-17
+22
-17
README.md
+22
-17
README.md
···
23
23
24
24
If you are working with a normal on-disk repository, start with
25
25
`repository.Open(...)`. It opens the repository and wires together the refs
26
-
storage, object storage, and fetcher. Note that it requires either a
27
-
bare repository or a `.git` directory. Then,
26
+
storage, object storage, fetcher, (optional) commit-graph, commit queries, and
27
+
reachability helpers. Note that it requires either a bare repository or a
28
+
`.git` directory. Then,
28
29
29
30
* `repo.Refs()` is for branch names, tags, `HEAD`, and ref updates.
30
31
* Use it when you are starting from names rather than object IDs.
···
47
48
* However, checking an object ID's size and type are somewhat common
48
49
operations that should be done here.
49
50
51
+
* `repo.CommitQueries()` is the main graph-query API.
52
+
* Use it when you need ancestor checks or merge-base computation.
53
+
54
+
* `repo.Reachability()` is the graph-traversal API.
55
+
* Use it when you need to walk reachable commits or objects, or to perform
56
+
connectivity checks.
57
+
58
+
* `repo.CommitGraph()` exposes the low-level commit-graph reader.
59
+
* Not all repositories have commit graphs, so it may be nil.
60
+
* Most callers should prefer `repo.CommitQueries()` or `repo.Reachability()`
61
+
unless they specifically need direct commit-graph access.
62
+
50
63
Note that:
51
64
52
65
* `object` contains parsed Git object values such as blobs, trees, commits, and
···
63
76
* If you want typed objects or path-based access, use `repo.Fetcher()`.
64
77
* If you need raw object lookup by ID, object headers, or object streams, use
65
78
`repo.Objects()`.
79
+
* If you need ancestor checks or merge bases, use `repo.CommitQueries()`.
80
+
* If you need commit or object graph traversal, use `repo.Reachability()`.
66
81
67
-
Some useful operations are separate and are meant to be constructed over the
68
-
stores that `Repository` already exposes:
69
-
70
-
* To check whether one revision is an ancestor of another, or to compute merge
71
-
bases, construct a `commitquery.Query` over `repo.Objects()`. If you already
72
-
have a commit-graph reader, pass it in as well for performance.
73
-
74
-
* To walk commits or all reachable objects from a set of starting points,
75
-
construct a `reachability.Reachability` over `repo.Objects()`. This is useful
76
-
for tasks such as connectivity checks and computing the object set that a
77
-
fetch or push needs to account for.
82
+
Some operations remain available if you want to work below those accessors:
78
83
79
84
* To accept pushes on the server side, construct `network/receivepack` or
80
85
`network/receivepack/service` with the repository's ref store, object store,
81
-
and object ID algorithm.
86
+
commit-graph reader, and object ID algorithm.
82
87
* Push handling also needs the repository's object storage root so incoming
83
88
objects can be quarantined and later promoted.
84
89
* `Repository` does not currently expose that root directly (we'll consider
85
90
possible solutions sometime later), so a push server usually keeps the
86
91
repository path or object root handle alongside the `Repository` value.
87
-
* Hook-based checks are just Go functions; then, a fast-forward check can use
88
-
`commitquery` over the existing and quarantined object stores. Some hooks
89
-
are provided.
92
+
* Hook-based checks are just Go functions; for example, a fast-forward check
93
+
can use `commitquery.Queries` over the existing and quarantined object
94
+
stores. Some hooks are provided.
90
95
91
96
## Alternatives
92
97