Fast implementation of Git in pure Go
codeberg.org/lindenii/furgit
git
go
TODO: update
+12
-21
+12
-21
TODO
+12
-21
TODO
···
27
27
* Completely redo error handling.
28
28
29
29
* Better status reporting, filling in more things in report-status-v2.
30
-
* Design some way to pass commit graphs to hooks.
31
30
* Maybe the Progress/Error writers should return error on creation
32
31
instead of automatically discarding content?
33
32
* Actually making signed-push work reasonably
34
33
* Investigate fsck issues with receive-pack
35
34
* Improve performance of delta resolution
36
35
37
-
* Okay, I think this is a pretty big design issue between the object
38
-
store and network operations: Things are modular enough that implementing
39
-
this probably doesn't break many other things, so it's not too big of a deal,
40
-
but it's an architectural debt that we should concsider: we have nice
41
-
pluggable object stores, but network-related paths like ingest still take an
42
-
*os.Root to write their quarantines and final packs into. This is fine for
43
-
the normal repository that uses Git packfiles, but would obviously not work
44
-
if we add something like dynamic packs, or want to write to any other sort of
45
-
object store. Perhaps object stores should get a batch writing interface? But
46
-
any general purpose, non-pack-aware writing interface would probably perform
47
-
significantly worse than just natively teeing the network pack (since what we
48
-
get from the network are always literally packs) to an indexer and the
49
-
filesystem. A possible design is to require implementations to implement
50
-
their own pack ingestion algorithm; but that would make it harder to have
51
-
alternative protocols in the future, however for now it seems like a valid
52
-
solution. When there is any sight of alternative, non-pack-based protocols in
53
-
the future, we should think of another way.
54
-
go-git handles it in their object stores but the way they
55
-
implement it is extremely complex and not fit for furgit
56
-
architecture.
36
+
* Okay, I think this is still a real design issue, just at a different layer
37
+
now. receive-pack and the object stores are better than they were when pack
38
+
ingest still wanted raw roots, and we now have coordinated quarantines and a
39
+
dual store to represent the normal mix. However, that probably isn't the end
40
+
state either. In the usual repository layout, loose and packed objects are
41
+
really two parts of one files object storage, and dual may just be an
42
+
intermediate abstraction until files-backed storage gets a more integrated
43
+
API, including in particular, ingress/quarantine. We should preserve the
44
+
current separation for now, because it keeps the boundaries there, and is
45
+
much simpler than trying to prematurely fuse everything together, but if
46
+
receive-pack and hooks keep growing around dual then that is probably a sign
47
+
that the underlying files object storage wants a interface of its own.
57
48
58
49
* Digital signature API
59
50
* Revision-ish entry points like if you get main or v1.0 we should