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