runxiyu.tngl.sh
Fast implementation of Git in pure Go
1So the to-do list in README.md is more
2
3* Better status reporting, filling in more things in report-status-v2.
4* Better progress reporting during network operations.
5* More accurate semantics for non-atomic batch updates:
6 - Git validates the batch against the transaction view while
7 we update against the actual store
8 - Duplicates should really just be a fatal transaction level issue
9 - Git basically makes it a single transaction with rejected entries
10 removed, but we basically commit each op separately, so
11 later operations see the live repository after earlier successful
12 ops. So, yeah, atomicity of the surviving subset.
13 - Definitely should stop string matching on errors
14* Design some way to pass commit graphs, or if possible, entire repo
15 objects to hooks. Unfortunately this is more difficult than it sounds.
16* Maybe the Progress/Error writers should return error on creation
17 instead of automatically discarding content?
18* Actually making signed-push work reasonably
19* Investigate fsck issues with receive-pack
20* Improve performance of delta resolution
21* Consider unifying how flush works.
22
23* Okay, I think this is a pretty big design issue between the object
24 store and network operations: Things are modular enough that implementing
25 this probably doesn't break many other things, so it's not too big of a deal,
26 but it's an architectural debt that we should concsider: we have nice
27 pluggable object stores, but network-related paths like ingest still take an
28 *os.Root to write their quarantines and final packs into. This is fine for
29 the normal repository that uses Git packfiles, but would obviously not work
30 if we add something like dynamic packs, or want to write to any other sort of
31 object store. Perhaps object stores should get a batch writing interface? But
32 any general purpose, non-pack-aware writing interface would probably perform
33 significantly worse than just natively teeing the network pack (since what we
34 get from the network are always literally packs) to an indexer and the
35 filesystem. A possible design is to require implementations to implement
36 their own pack ingestion algorithm; but that would make it harder to have
37 alternative protocols in the future, however for now it seems like a valid
38 solution. When there is any sight of alternative, non-pack-based protocols in
39 the future, we should think of another way.